Silfur Engine # 2: DLLight and Boost your code

Hi everyone :)

Welcome to this new devlog which will clarify a little why it only took a simple sequence of macro in the header Core.h to define the symbol of import or export of the DLL.

I will also give some useful links for the installation of the Boost library. It's a very powerful library that optimizes some functions of the standard library, automates some of the codes that are often rewrite and developers have created effective tools that can be brought to use.

Light on DLL

As a reminder, it was enough for this simple code to import / export the symbols (names of classes, functions, variables, ...) That's all that we want to make public to the application from this DLL.

So how is it that our code knows what is the macro SILFUR_API if we develop our application?

Just because in your application, you will never define the SF_BUILD_DLL macro. This macro is specific to the compilations options of the engine and his developers. Your application doesn't need to define it. As a result, SILFUR_API will always be __declspec(dllimport).

When you compile the application, I designed the engine to include only the Silfur.h header. That contains all the headers that can be used by the application.

If this engine gets very big, I will refactor the code to get it right: IWYU (Include-What-You-Use) to avoid aberrant compiling times or create small "packages" of includes.

And then, in each of the headers of the engine where it is necessary (that I want to go public to use it in the application therefore), I included the header Core.h even before the definition of the symbols (class names in most cases). In this way, the code is compiled with SILFUR_API equal to __declspec(dllimport) and the compiler can use the DLL correctly.

For more details on this subject, I invite you to read this page and those associated (on the menu on the left):

Library Boost

The Boost library is more exactly a set of lots of different libraries, downloadable here:

For the installation, there's the official documentation on Windows or Unix systems. But clearly, the best explanation, with VS2017, that I was given to use is this: Just replace boost_1_64_0 by boost_1_69_0 (when I wrote this devlog, pay attention to the version you have).

And finalize the configuration in your project using property sheets with VS2017 :

NB: I had the problem described at the bottom of the page of this last link. Just follow the explanations on the properties of your project and NOT the property sheet.

For the documentation of Boost, I will not spread on each available libraries. There are ... a lot! I invite you to be curious about what is available and what you need.

Thank you for reading!

Leave a comment

Log in with to leave a comment.