I have created a C++ module which has an API part and an internal part. The API contains a long (more then 30) list of polymorphic classes inheriting directly or indirectly from the same baseclass. In my internal classes/functions these classes are used differently, so I moved some functionality to these classes to be used polimorphically. These functionalites depend on some internal resources, while the internal functions depend on these classes so I broke this circular dependency by forward declaring the necessary classes in the .h files and including them in the .cpp files. This way my module compiles and works perfectly.
Here comes the problem. When I include the API from another module, I get "undefined reference to ...." errors to internal functions in the API classes polimorphic functions. I think this is due to the forward declarations. These internal classes are never defined in the eyes of the second module which uses the API.
Broadly my module looks like this:
InternalClass.h:
class ApiObjBase;
class InternalClass {
public:
static InternalClass& get(); // singleton
void processApiObjBase(ApiObjBase& apiObj);
static const Resource& getResource1();
static const Resource& getResource2();
static const std::map<uint64_t, std::unique_ptr<ApiObjBase>>& getApiObjStorage();
UacManager(const UacManager&) = delete; // singleton
UacManager& operator=(const UacManager&) = delete; // singleton
private:
InternalClass(); // singleton
Resource resource1;
Resource resource2;
std::map<uint64_t, std::unique_ptr<ApiObjBase>> ApiObjStorage;
}
InternalClass.cpp:
#include "ApiObjBase.h"
void InternalClass::processApiObjBase(ApiObjBase& apiObj) {
apiObj.internalPolyFunc1();
apiObj.internalPolyFunc2();
// ...
}
const Resource& InternalClass::getResource1() {
return get().resource1;
}
const Resource& InternalClass::getResource2() {
return get().resource2;
}
// Other implementations of member functions ...
ApiObjBase.h:
class InternalClass;
class ApiObjBase {
protected:
int internalVariable1;
int internalVariable2;
int apiVariable1;
int apiVariable2;
public:
ApiObjBase() = default;
// getters, setters
void internalPolyFunc1() = 0;
void internalPolyFunc2() = 0;
void apiPolyFunc1() = 0;
void apiPolyFunc2() = 0;
}
ApiObjBase.cpp:
#include "ApiObjBase.h"
// ...
ApiObjDerived1.h:
#include "ApiObjBase.h"
class ApiObjDerived1 : public ApiObjBase {
protected:
int internalVariable3;
int internalVariable4;
int apiVariable3;
int apiVariable4;
public:
ApiObjDerived1() = default;
// getters, setters
void internalPolyFunc1() override;
void internalPolyFunc2() override;
void apiPolyFunc1() override;
void apiPolyFunc2() override;
}
ApiObjDerived1.cpp:
#include "ApiObjDerived1.h"
#include "InternalClass.h"
void ApiObjDerived1::internalPolyFunc1() {
Resource& res = InternalClass::getResource1(); //
// ...
}
void ApiObjDerived1::internalPolyFunc2() {
Resource& res = InternalClass::getResource1();
// ...
}
void ApiObjDerived1::apiPolyFunc1() {
// ...
}
void ApiObjDerived1::apiPolyFunc2() {
// ...
}
// ...
ApiObjDerived2.h:
#include "ApiObjBase.h"
class ApiObjDerived2 : public ApiObjBase {
protected:
int internalVariable5;
int internalVariable6;
int apiVariable5;
int apiVariable6;
public:
ApiObjDerived2() = default;
// getters, setters
void internalPolyFunc1() override;
void internalPolyFunc2() override;
void apiPolyFunc1() override;
void apiPolyFunc2() override;
}
ApiObjDerived2.cpp:
#include "ApiObjDerived2.h"
#include "InternalClass.h"
void ApiObjDerived2::internalPolyFunc1() {
Resource& res = InternalClass::getResource2();
// ...
}
void ApiObjDerived2::internalPolyFunc2() {
// ...
}
void ApiObjDerived2::apiPolyFunc1() {
// ...
}
void ApiObjDerived2::apiPolyFunc2() {
// ...
}
// ...
SomeOtherModule.cpp:
#include "ApiObjDerived2.h"
void main(int argc, char** argv) {
std::unique_ptr<ApiObjBase> apiObj = std::make_unique<ApiObjDerived2>();
apiObj.get()->apiPolyFunc1();
return EXIT_SUCCESS;
}
For this example the error would the following while linking SomeOtherModule:
(...) In function `ApiObjDerived2::internalPolyFunc1()':
(...) undefined reference to `InternalClass::getResource2()'
My only idea to this problem is to create wrapper classes (ApiObjBaseWrapper, ApiObjDerived1Wrapper, ApiObjDerived2Wrapper) for each polymorphic class and move all internal member variables and functions to them. These wrapper classes would contain the original derived class as a private member variable, which could be accessed by a virtual getter which returns a reference or a pointer to ApiObjBase. This would separate the internal and API part of the module making predeclarations unnecessary in the API, while maintaining all the advantages of polymorphism. After this, InternalClass could use ApiObjBaseWrapper, and SomeOtherModule could continue to use ApiObjBase.
My problem with this idea is that this would require a LOT of new files, classes and code (I would have to create another ~30 classes with .cpp and .h files). I cannot emphasize more how big this module is.
What do you suggest, what should I do?
Related
Dotnet dev with embedded C experience here moving into cpp land to give you an idea of my experience/knowledge.
I've got a base class Window in src/Core/Window/:
namespace Pyrite::Core::Window
{
class PYR_API Window
{
public:
using EventCallbackFn = std::function<void(Pyrite::Event&)>;
virtual ~Window();
virtual void OnUpdate();
virtual uint32_t GetWidth() const = 0;
virtual uint32_t GetHeight() const = 0;
virtual void SetEventCallback(const EventCallbackFn& callback) = 0;
virtual void SetVSync(bool isEnabled) = 0;
virtual bool IsVSyncEnabled() const = 0;
static Window* Create(const WindowProperties& props = WindowProperties());
};
}
From this, I have created a derived class for the platform-specific WindowsWindow, I want to store this in src/Core/Window/Platform/:
namespace Pyrite::Core::Window::Platform
{
class WindowsWindow : public Pyrite::Core::Window::Window
{
public:
WindowsWindow(const WindowProperties& properties);
virtual ~WindowsWindow();
void OnUpdate() override;
inline uint32_t GetWidth() const override { return m_Data.Width; }
inline uint32_t GetHeight() const override { return m_Data.Height; }
inline void SetEventCallback(const EventCallbackFn& callback) override { m_Data.EventCallback = callback; }
void SetVSync(bool isEnabled) override { m_Data.VSyncEnabled = isEnabled; }
bool IsVSyncEnabled() override {return m_Data.VSyncEnabled; }
private:
virtual void Init(const WindowProperties& properties);
virtual void Close();
GLFWwindow* m_Window;
struct WindowData
{
std::string Title;
uint32_t Width, Height;
bool VSyncEnabled;
EventCallbackFn EventCallback;
};
WindowData m_Data;
};
}
However, in WindowsWindow.cpp, when I try to create my implementation for Window::Create() I get an error about not being able to define it here:
namespace Pyrite::Core::Window::Platform
{
static bool s_GLFWInitialised = false;
Window* Window::Create(const WindowProperties& properties)
{
return new WindowsWindow(properties);
}
}
'Pyrite::Core::Window::Window *Pyrite::Core::Window::Window::Create(const Pyrite::Core::Window::WindowProperties &)': symbol cannot be defined within namespace 'Platform' PyriteEngine C:\repos\Pyrite\PyriteEngine\src\Core\Window\Platform\WIndowsWindow.cpp 9
When I adjust the namespaces so they're all sat in Pyrite::Core::Window it seems to go away... However, it seems odd to me that I can't define this in the subnamespace. I want my namespaces to follow my folder structure if possible (as that's pretty much what I'm used to and it keeps things logical and uncluttered) and hiding the platform specific stuff away in a subnamespace seems to make sense to me.
Is this just something I flat out can't do or am I missing something here?
First, the separation between source files and namespaces in C++ is a feature in that they can follow the same structure if appropriate but other organizations are also possible. Beyond that, it’s impossible to do (literally) what you ask, because it produces weird “siblings” for name lookup that are considered to be more trouble than they’re worth. In particular, given
namespace A {
int i;
struct X {void f(); void g(); void h();};
namespace B {
void g();
namespace C {
int i;
void h();
void X::f() {g(); h(); ++i;} // pretend this is OK
}
}
}
it’s not entirely clear whether B::g and/or C::h are “closer” to the definition of X::f than X::g or X::h. It’s also not clear that it’s desirable to have moving X::f’s definition into or out of the class change which i is found.
You can often use using-declarations to work around these limitations: X above might be defined in B but then exposed in A (or in C!). Sometimes the affected member functions can alternatively be moved into a base class that belongs to a different namespace.
I want to load libraries at run time. I have a base class "Base" and two derived classes "Derived1" and "Derived2" which should be loaded at runtime. I am using the approach from this answer with some small modifications. The code compiles perfectly when I define only one derived class, but it fails to compile when several derived classes are defined. The compilation error is the following:
multiple definitions of 'create'
I think that the problem is "C" doesn't allow overloading of function names. How would one solve this problem?
The important point is that since I don't know how many .so files exist, I want to have one handler for all .so files. The details of the code are given below:
base.hpp:
class Base {
public:
virtual ~Base() {}
virtual void foo() const = 0;
};
using Base_creator_t = Base *(*)();
derived1.hpp:
#include "Interface.hpp"
class Derived1: public Base {
public:
void foo() const override {}
};
extern "C" {
Base * create() {
return new Derived1;
}
}
derived2.hpp:
#include "Interface.hpp"
class Derived2: public Base {
public:
void foo() const override {}
};
extern "C" {
Base * create() {
return new Derived2;
}
}
Dynamic shared library handler: Derived_factory.hpp:
#include <dlfcn.h>
class Derived_factory {
public:
Derived_factory(char* path) {
handler = dlopen(path, RTLD_NOW);
if (! handler) {
throw std::runtime_error(dlerror());
}
Reset_dlerror();
creator = reinterpret_cast<Base_creator_t>(dlsym(handler, "create"));
Check_dlerror();
}
std::unique_ptr<Base> create() const {
return std::unique_ptr<Base>(creator());
}
~Derived_factory() {
if (handler) {
dlclose(handler);
}
}
private:
void * handler = nullptr;
Base_creator_t creator = nullptr;
static void Reset_dlerror() {
dlerror();
}
static void Check_dlerror() {
const char * dlsym_error = dlerror();
if (dlsym_error) {
throw std::runtime_error(dlsym_error);
}
}
};
main.cpp:
#include "Derived_factory.hpp"
int main(){
Derived_factory factoryOne("Derived1.so");
std::unique_ptr<Base> baseOne = factoryOne.create();
baseOne->foo();
Derived_factory factoryTwo("Derived2.so");
std::unique_ptr<Base> baseTwo = factoryTwo.create();
baseTwo->foo();
return 0;
}
The problem is not extern "C". The problem is you have multiple definitions of the same function.
Base * create() is indistinguishable from Base * create()
What you're trying to do is to have the same function in two different loadable modules. But what you're doing instead is putting both implementations (with the same name and signature!) of this function into the main module, which of course results in multiple definition error.
What you should do instead is put the create functions into the *.cpp files, i.e. derived1.cpp and derived2.cpp, omit their definitions from the *.hpp files, and compile the shared objects from these *.cpp files. I've modified your project to achieve this, see the live demo.
I have an object "World obj;" that has a normal interface of methods for it's typical funcitonality, but I want to have an additional interface of methods specifically for initializing that should only be visible when I specifically need them.
An example might be like this:
class World{
public:
void draw();
void update();
void normalStuff();
void addATree(); // this should not be ordinarily available or visible,
void addACar(); // calling this might break the object
void addAClown();// if it's not in a ready state for it
private:
int m_data;
};
Is there a way to relatively hide addATree(); etc in a way that makes sense? Ideally the mechanism for revealing those methods would also put the object into a ready state for them, or at least fault if it's not possible.
Different approaches would be possible:
Don't change the code, just change the spec
No need to change the code. Change the API specification and if the caller throws garbage in he gets garbage out.
Make the functions check if they are allowed
Always safe.
class World{
public:
...
void addAClown() {
if(not allowed)
throw error or crash or output error message or just return;
else {
do the work;
}
}
private:
int m_data;
};
Write a function that only exposes the Interface if allowed
You can't protect against someone getting the interface early and use it longer than allowed.
You could extract the interface functions into a separate class.
class WorldInterfaceToProtect {
public:
void addATree() = 0; // this should not be ordinarily available or visible,
void addACar() = 0; // calling this might break the object
void addAClown() = 0;// if it's not in a ready state for it
};
then the main class can protect these functions.
class World : protected WorldInterfaceToProtect {
public:
void draw();
void update();
void normalStuff();
protected:
void addATree(); // this should not be ordinarily available or visible,
void addACar(); // calling this might break the object
void addAClown();// if it's not in a ready state for it
private:
int m_data;
};
You then need to add a function that exposes the interface.
class World ... {
public:
WorldInterfaceToProtect *GetInterface() { return allowed_cond ? this : nullptr; }
...
}
Separate the class itself and the builder
This only helps if the functions to be called are only allowed during construction and not later. Depending on the design of the builder you can get a good protection.
class World{
friend class WorldBuilder;
public:
void draw();
void update();
void normalStuff();
protected:
void addATree(); // this should not be ordinarily available or visible,
void addACar(); // calling this might break the object
void addAClown();// if it's not in a ready state for it
private:
int m_data;
};
class WorldBuilder {
static World *Build(...);
}
Perhaps split the world into more composable parts:
struct WorldInterface
{
virtual void draw() = 0;
virtual void update() = 0;
virtual void normalStuff() = 0;
};
class World : public WorldInterface
{
public:
void draw() override { /* actual drawing here */};
void update() override {};
void normalStuff() override {};
private:
int m_data;
};
class TreeWorld : public WorldInterface
{
public:
// takes a reference to the actual world engine and defers work to
// that
TreeWorld(World& worldEngine) : worldEngine_(worldEngine) {}
void draw() override { worldEngine_.get().draw(); };
void update() override { worldEngine_.get().update(); };
void normalStuff() override { worldEngine_.get().normalStuff(); };
void addATree() {
//do tree/world interaction here
}
private:
std::reference_wrapper<World> worldEngine_;
};
class CarWorld : public WorldInterface
{
public:
// takes a reference to the actual world engine and defers work to
// that
CarWorld(World& worldEngine) : worldEngine_(worldEngine) {}
void draw() override { worldEngine_.get().draw(); };
void update() override { worldEngine_.get().update(); };
void normalStuff() override { worldEngine_.get().normalStuff(); };
void addACar() {
//do car/world interaction here
}
private:
std::reference_wrapper<World> worldEngine_;
};
extern void play_tree_game(TreeWorld world);
extern void play_car_game(CarWorld world);
int main()
{
World worldEngine;
// initialise engine here
// play tree-phase of game
play_tree_game(TreeWorld(worldEngine));
// play car phase of game
play_car_game(CarWorld(worldEngine));
}
Good answers all around, I'll just add this because it was missing(?)
class World{
public:
void draw();
void update();
void normalStuff();
private:
int m_data;
};
class BuildableWorld : public World
{
public:
void addATree();
void addACar();
void addAClown();
};
Use the BuildableWorld at initialization phase and then just give a pointer to the base class type for others to use.
Sure, you need some way to give the "built" data for the base class to access, but that was not the issue here, right?
an alternative approach that has not been mentioned so far, may be to let addX() functions take parameters whose existence implies that World is in a valid state. Say, if you cannot add trees to a world without water, let World return an (optional) water object to pass to addTree ... in other words, you need to properly formalize World invariants:
class World{
public:
void normalStuff();
auto getAvaliableWaterBuckets() -> optional<WaterBuckets>;
auto getAvaliableSoil() -> optional<SoilPack>;
//...
void addATree( WaterBuckets&&, SoilPack&& );
//...
};
// in the meanwhile, in user land:
if( auto water = world->getAvaliableWaterBuckets() )
if( auto soil = world->getAvaliableSoil() )
world->addTree( std::move(*water), std::move(*soil) );
else
world->recycleWater( std::move(*water) );
the benefit of this approach is that the user is not forced to think about world state validity ( an error prone task ), he just thinks about what he needs in order to add a tree ( simpler, hard to use incorrectly ). Moreover, this scales well because addX() functions can share different objects ( addFlowers needs water, ... ) enabling the correct management of a possibly complex internal world state.
Of course, IMHO, if you need to use addX() strictly on world construction only ( and you don't plan to add trees later ), then the factory approach already mentioned in the comments seems the way to go ...
I tried using a debug flag addition (GOOGLE_TEST) in the source code and defined it in the TEST/Makefile.am. but the things didn’t work. I am using C++ Language.
Note: I don’t want to change anything in the SRC Directory code which will affect the production code and its Makefile.am
Test Class in SRC Directory
class Common: public Thread {
public:
friend class test_common;
Common {
}
~Common () {
}
virtual void ThreadMain();
protected:
virtual void ProcessData(void);
};
void Common::ProcessData(void) {
#ifndef __GOOGLE_TEST__
while (1) { }
#endif
}
TESTCODE in test Directory
class test_common : public ::testing::Test {
};
TEST_F(test_common, create_common) {
Common commonObj();
commonObj. ProcessData ();
}
OUTPUT
GTest Stuck in the While loop part even after defining the flag in the test/makefile.am
Dont rely on the compilation flags, without affecting the production code use the GMOCK methods to get rid off the while (1) loop , the code can go like below:
TESTCODE:
class test_common : public ::testing::Test {
};
TEST_F(test_common, create_common) {
Common commonObj();
ON_CALL(mock_if, GetBool())
.WillByDefault(Return(true));
EXPECT_CALL(mock_if, GetBool())
.Times(AtLeast(1))
.WillOnce(Return(true))
.WillOnce(Return(false));
commonObj. ProcessData ();
}
ABSTRACT CODE:
class AbstractIf {
public:
AbstractIf (void) = default;
virtual ~AbstractIf (void) = default;
virtual bool GetBool() = 0;
};
MOCK CODE:
class MockIf : public AbstractIf {
public:
MOCK_METHOD0(GetBool,bool());
};
SOURCE CODE:
class Common: public Thread {
public:
friend class test_common;
Common {
}
~Common () {
}
virtual void ThreadMain();
protected:
virtual void ProcessData(void);
AbstractIf *prov_fl_if_;
};
void Common::ProcessData(void) {
while (prov_fl_if_->GetBool()) { }
}
By this way we can skip the part of the code we want without affecting the production code
There is no way to make a #define value from one compilation unit affect the compilation of another, previously compiled units. Given the list of things you have stipulated you don't want to do, you will have to use some form of runtime shenanigans.
You could make ProcessData take an argument that determines whether the loop should iterate:
void ProcessData(bool once=false);
void Common::ProcessData(bool once) {
do {
// ... your loop code
} while (!once);
}
Or you could use a global variable that is defined in the module with your main() in it, lets call it main.cpp.
Production main.cpp:
const bool g_isDebugMode = false;
Unit test main.cpp:
const bool g_isDebugMode = true;
main.h
extern const bool g_isDebugMode;
now you can write runtime tests against this variable.
do {
// your code
} while (g_isDebugMode == false);
I need several C++ classes to have a static method "register", however the implementation of register varies between those classes.
It should be static because my idea is to "register" all those classes with Lua (only once of course).
Obviously I can't declare an interface with a static pure virtual function. What do you guys suggest me to do ? Simplicity is welcome, but I think some kind of template could work.
Example of what I would like to achieve
class registerInterface
{
public:
static virtual void register() = 0; //obviously illegal
};
class someClass: public registerInterface
{
static virtual void register()
{
//I register myself with Lua
}
}
class someOtherClass: public registerInterface
{
static virtual void register()
{
//I register myself with Lua in a different way
}
}
int main()
{
someClass::register();
someOtherClass::register();
return 0;
}
Based on how you've described the problem, it's unclear to me why you even need the 'virtual static method' on the classes. This should be perfectly legal.
class SomeClass {
static void register(void) {
...
}
}
class SomeOtherClass {
static void register(void) {
...
}
}
int main(int argc, char* argv[]) {
SomeClass::register();
SomeOtherClass::register();
return 0;
}
Drop the RegisterInterface, I don't think you need it.
If it helps, you could take Hitesh's answer, and add:
struct luaRegisterManager {
template <typename T>
void registrate() {
T::registrate();
// do something else to record the fact that we've registered -
// perhaps "registrate" should be returning some object to help with that
}
};
Then:
int main() {
luaRegisterManager lrm;
lrm.registrate<someClass>();
lrm.registrate<someOtherClass>();
}
More generally, if you want to introduce any dynamic polymorphism in C++, then you need an object, not just a class. So again, perhaps the various register functions should be returning objects, with some common interface base class registeredClass, or classRegistrationInfo, or something along those lines.
Could provide an example of what you feel it is that you need dynamic polymorphism for? Hitesh's code precisely matches your one example, as far as I can see, so that example must not cover all of your anticipated use cases. If you write the code that would be using it, perhaps it will become clear to you how to implement it, or perhaps someone can advise.
Something else that might help:
#include <iostream>
#include <string>
#include <vector>
struct Registered {
virtual std::string name() = 0;
virtual ~Registered() {}
Registered() {
all.push_back(this);
}
static std::vector<Registered*> all;
};
std::vector<Registered*> Registered::all;
typedef std::vector<Registered*>::iterator Iter;
template <typename T>
struct RegisteredT : Registered {
std::string n;
RegisteredT(const std::string &name) : n(name) { T::registrate(); }
std::string name() { return n; }
// other functions here could be implemented in terms of calls to static
// functions of T.
};
struct someClass {
static Registered *r;
static void registrate() { std::cout << "registering someClass\n"; }
};
Registered *someClass::r = new RegisteredT<someClass>("someClass");
struct someOtherClass {
static Registered *r;
static void registrate() { std::cout << "registering someOtherClass\n"; }
};
Registered *someOtherClass::r = new RegisteredT<someOtherClass>("someOtherClass");
int main() {
for (Iter it = Registered::all.begin(); it < Registered::all.end(); ++it) {
std::cout << (*it)->name() << "\n";
}
}
There are all sorts of problems with this code if you try to split it across multiple compilation units. Furthermore, this kind of thing leads to spurious reports from memory leak detectors unless you also write some code to tear everything down at the end, or use a vector of shared_ptr, Boost pointer vector, etc. But you see the general idea that a class can "register itself", and that you need an object to make virtual calls.
In C++ you usually try to avoid static initialisation, though, in favour of some sort of setup / dependency injection at the start of your program. So normally you would just list all the classes you care about (calling a function on each one) rather than try to do this automatically.
Your intentions are noble, but your solution is inkling towards "overengineering" (unless I am missing an obvious solution).
Here is one possibility: You can use the Virtual Friend function idiom For example,
class RegisterInterface{
friend void register(RegisterInterface* x){x->do_real_register();}
protected:
virtual void do_real_register();
}
class Foo : public RegisterInterface{
protected:
virtual void do_real_register(){}
};
class Bar : public RegisterInterface{
protected:
virtual void do_real_register(){}
};
int main(int argc, char* argv[]) {
BOOST_FOREACH(RegisterInterface* ri, registered_interfaces)
{
register(ri);
}
return 0;
}
I know you've already accepted an answer, but I figured I would write this up anyway. You can have self-registering classes if you use some static initialization and the CRTP:
#include <vector>
#include <iostream>
using namespace std;
class RegisterableRoot // Holds the list of functions to call, doesn't actually need
// need to be a class, could just be a collection of globals
{
public:
typedef void (*registration_func)();
protected:
static std::vector<registration_func> s_registery;
public:
static void do_registration()
{
for(int i = 0; i < s_registery.size(); ++i)
s_registery[i]();
}
static bool add_func(registration_func func) // returns something so we can use it in
// in an initializer
{
s_registery.push_back(func);
return true;
}
};
template<typename RegisterableType> // Doesn't really need to inherit from
class Registerable : public RegisterableRoot // RegisterableRoot
{
protected:
static const bool s_effect;
};
class A : public Registerable<A> // Honestly, neither does A need to inherit from
// Registerable<T>
{
public:
static void Register()
{
cout << "A" << endl;
}
};
class B : public Registerable<B>
{
public:
static void Register()
{
cout << "B" << endl;
}
};
int main()
{
RegisterableRoot::do_registration();
return 0;
}
std::vector<RegisterableRoot::registration_func> RegisterableRoot::s_registery;
template <typename RegisterableType> // This is the "cute" part, we initialize the
// static s_effect so we build the list "magically"
const bool Registerable<RegisterableType>::s_effect = add_func(&RegisterableType::Register);
template class Registerable<A>; // Explicitly instantiate the template
// causes the equivalent of
// s_registery.push_back(&A::Register) to
// be executed
template class Registerable<B>;
This outputs
A
B
although I wouldn't rely on this order if I were you. Note that the template class Registerable<X> need not be in the same translation unit as the call to do_registration, you can put it with the rest of your definition of Foo. If you inherit from Registerable<> and you don't write a static void Register() function for your class you'll get a (admittedly probably cryptic) compiler error much like you might expect if there really was such a thing as "static virtuals". The "magic" merely adds the class specific function to the list to be called, this avoids several of the pitfalls of doing the actual registration in a static initializer. You still have to call do_registration for anything to happen.
How about this way? Define an interface class:
// IFoobar.h
class IFoobar{
public:
virtual void Register(void) = 0;
}
Then define the class that handles the register..
// RegisterFoobar.h
class RegisterFoobar{
public:
// Constructors etc...
IFoobar* fooBar;
static void RegisterFoobar(IFoobar& fubar){
foobar = &fubar;
}
private:
void Raise(void){ foobar->Register(); }
}
Now, then define another class like this
// MyFuBar.h
class MyFuBar : IFoobar{
public:
// Constructors etc...
void Register(void);
private:
RegisterFoobar* _regFoobar;
}
Call the code like this:
//MyFuBar.cpp
MyFuBar::MyFuBar(){
_regFoobar = new Foobar();
_regFoobar->RegisterFoobar(this);
}
void MyFuBar::Register(void){
// Raised here...
}
Maybe I have misunderstood your requirements...