views:

61

answers:

3

I have to work out a small framwork that is going to be used by several of our applications. On top of this, the framework is going to be used multiple times within the same application, but with a slightly different configuration. The 'nature' of the configuration is more complex than just having some configuration options and some setters. In practice, the application has to deliver its own data structures that will be incorporated in the framework, making it even more complex.

I can see the following 4 alternatives in writing the framework:

  • Put the common logic in a base class, and tell the application that it should inherit from this base class
  • Put the logic in a templated class, in which the application should pass its own class implementation
  • Describe the application's specific configuration in a configuration file and generate C++ code during the build process
  • Provide macro's that can be used to expand the 'configuration' to actual code

Which arguments should be taken into account when choosing a good alternative?

Are some of these alternatives better than other, and why?

Notice that in my case, performance is a top-priority.

A: 

Use a platform-specific header file. That's an additional alternative, similar to macros but without the cruft.

If you must use macros, do so only within the config header that includes the platform-specific header. But usually it's sufficient to define platform-specific structs and use them as subobjects.

Potatoswatter
A: 

What do you mean by performance? If it's the performance of final code running, remember that the solution with class inheritance that involves virtual function will involve a small overhead when calling them.

Other solutions induce additional overhead for project's build phase and also a slightly larger executable due to "duplication" of code (via template concretisation, custom code generation or macro expansion).

Xion
+1  A: 

I would avoid runtime polymophism if peak performance really is an issue not only because the vtable lookup for virtual function calls but because:

  • inlining virtual calls to allow efficient cross function boundary optimizations is sort of difficult to do (the same applies to generated code compiled to a shared library loaded at runtime ("plugin") and statically linked modules compiled from generated code utilizing a compiler that doesn't support link time optimizations).
  • polymorphic objects usually have to be heap allocated to avoid slicing, possibly creating additional runtime overhead

Macros tend to be hard to debug, so unless you need their ability to do string concatenations, which is their distinctive advantage over templates in some cases, I would personally go for a template based solution using static polymorphism techniques like, as you indicated, the curiously recurring template pattern and/or, if applicable, template specializations to handle custom data structures.

Mike