Day 1 : 8 June 2022 : Where to Start?

My 100 Daze of Code

Where to Start?

So, we need to take some things into consideration when planning a multi-platform solution. Coding a library in C++ looks a little different on various operating systems. Also, where to start? Best to keep it simple at first. And, try to avoid anything that might get us stuck later if our code become platform-specific. At the same time, we can define an overall structure pretty early on and then fill out the details progressively.

For day 1, let's just define a simple class we can export from the library. The class can have one method that simply outputs "Hello, World!" so that we can confirm that it gets called. We can build the library using a simple Makefile to begin with and add other build methods later. Our driver program needs only a main routine that calls the library method. We can worry about the test program later on.

As for platforms, we'll start on Linux. We'll need to clone our repo from Github, create a source folder, create our library class source file (.cpp) and any headers (.h) that we need. Create a driver source file (.cpp) and a simple Makefile. Then we'll build using "make" and run the created driver program.

Linux

I'm running Linux Mint Debian Edition (LMDE) as a virtual machine (VM) under Oracle's Virtual Box hypervisor. Set the networking to NAT (network address translation) to get an IP assigned by the host that can reach the interwebs.

Git

Configure git with your user name and email. 


Clone the 100-days-of-code project.

Visual Code

If you haven't already installed Visual Code yet, do that now. Change directory into the 100-days-of-code folder and start code.

$ sudo apt install code
$ code .

I'll install the C/C++ Extension Pack from Microsoft to support debugging, etc.


I created a "src" folder and we'll define an api.h header to define some cross-platform definitions, a "Driver" class .cpp and .h file for the Ava library and a main.cpp file for the executable.

api.h

The "api" header is boilerplate. For now it simply defines "EXPORT" as is appropriate for Windows, Linux and macOS, to inform the build as to how to export or import library symbols.

driver.h

The "driver" header exposes a public interface, IDriver. Since the implementation will be in the library, we want to export the class constructor, destructor and a single method for now. We don't want this public header to expose the implementation details, however. So we'll adopt the unfortunately-named "PIMPL" (pointer to implementation) technique and encapsulate a private Driver class.

driver.cpp

The "driver" implementation in driver.cpp defines the private Driver class as well as the public IDriver interface. For now, "Hello" simply outputs a message to the standard output stream.

main.cpp

The "main" module will instantiate IDriver and invoke its public "Hello" method. 


Makefile

Our "Makefile" basically here as an example. We'll migrate to using CMake fairly soon. We'll compile and build libava.so to include driver.o and ava to include main.o.


Note that when you add a "Makefile" to a folder in Visual Code, the system will prompt you whether to install recommended extensions. I didn't install any Makefile extension.

Build and Run

From the console, run "make", "sudo make install" and "ldconfig" to build, install and refresh the library loader configuration. Then run "ava".

Debug

Create a "launch.json" file in the ".vscode" folder so that we can debug in Visual Code. You will have installed the "gdb" debugger beforehand.

{
"version": "0.2.0",
"configurations":[
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/src/ava",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb"
}
]
}

Press the "F5" key to start the debugger. We set "stopAtEntry" to true so that the debugger will wait at the first instruction.


Select the "Terminal" output window and single step over the call to Driver.Hello(). Observe the desired output.

Update the Project

Stage all changes, commit and push to the project repository in github.


Okay, so tomorrow, we'll start porting this to Windows.









 

Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more