Question: Modifiable class macro discovery within static libs about runtimecompiledcplusplus

[dougbinks]

Could it be that the entire class is being optimized out when it is within the subModule, but not when it is within Main.exe? As moving RuntimeObject01 from SubModule to Main.exe resolves this.

This sounds very plausible - though I see this as a bug in the linker since the static constructor has a side effect, however I see a similar issue online:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/5c5ee89d-2a38-483d-8550-484550901170/issues-with-static-variables-in-static-libraries?forum=vclanguage

It looks like you may need to use: #pragma comment(linker, "/include:SymbolToUse") where SymbolToUse is your class. When I get time I'll take a look to see if there is a way to add this to the REGISTER* macros when needed.

[dougbinks]

If the library and your main executable are both linked against the same version of the RuntimeObjectSystem library then the class registration via PerModuleInterface::GetInstance()->AddConstructor( this ) should register the class visible to code in Main.exe.

Perhaps place a break point on that line to see what happens?

[Alyx6020]

Same RuntimeObjectSystem lib is linked to both the static lib and Main.exe.

Tested using both #pragma comment(lib,"RuntimeObjectSystem.lib") and manually via project settings.

PerModuleInterface::GetInstance()->AddConstructor( this )
Only fires for any runtime classes within the Main.exe and any classes that have the REGISTERSINGLETON macro outside of its own class.
ie.

#myClass.cpp  (created outside of the RuntimeObjectSystem)
REGISTERSINGLETON(InterfaceLink, true);

causes the expected result of
0x023b4a08 {client.exe!TObjectConstructorConcrete<TActual<InterfaceLink>> TActual<InterfaceLink>::m_Constructor} {...}

However still doesn't discover classes that self delclare the macro within the static lib
ie.
RawInputI.h pure virtual class RawInputI : public IObject
RawInput.h class RawInput : public TInterface<ID_RCPP_INPUT, RawInputI>
RawInput.cpp #include "ObjectInterfacePerModule.h" REGISTERSINGLETON(RawInput, true);

[dougbinks]

any classes that have the REGISTERSINGLETON macro outside of its own class.

I don't quite understand what you mean by this.

A work around so far has been to place the REGISTERSINGLETON/REGISTERCLASS macro within another file that isn't loaded via RunTimeObjectSystem but this obviously isn't ideal.

Reading your first comment I'm also not sure I understand what you mean by this either.

In a few days I will have some time and I'll take a look at creating a small example project to see if I can replicate this.

[Alyx6020]

Reading your first comment I'm also not sure I understand what you mean by this either.

If I take the base example class RuntimeObject01.cpp the REGISTERCLASS macro is defined within the .cpp file of its own class.

Doing this when the class is within the SubModule(static lib) it isn't discovered.
However if I remove the macro from RuntimeObject01and place it in another cpp that is already used ie some initalization file for the subModule. It runs as expected and RuntimeObjectSystem is able to discover it.

//Initalization.cpp
REGISTERSINGLETON(SubModuleClass0, true);  //<- all loaded and visible as constructors within RuntimeObjectSystem
REGISTERCLASS(SubModuleClass1);
REGISTERCLASS(SubModuleClass2);

Initalization()  // <- This class is constructed normally outside of the RuntimeObjectSystem
{
   ... 
}

Could it be that the entire class is being optimized out when it is within the subModule, but not when it is within Main.exe? As moving RuntimeObject01 from SubModule to Main.exe resolves this.

Hopefully that clears it up a bit and thanks for the help thus far

[Alyx6020]

#pragma comment(linker, "/include:SymbolToUse") does indeed fix the issue. Seems the linker throws out anything that isn't linked by the main executable. Only snag is the symbol has to be the mangled/decorated name - to which I've been unable to find a flexible solution. __FUNCDNAME__ is close but has to be within the constructor.

[dougbinks]

If any function which references the constructor is included, then I think this should force the constructor and the registered class to be included in linking.

A quick test of this would be to modify the REGISTERBASE macro so that the definitions of GetTypeNameStatic become:

template<> const char* TActual< T >::GetTypeNameStatic() { return #T; \
__pragma( comment(linker, "/include:" __FUNCDNAME__) ) \
 } \

This is MS Specific and I should add macro around this, but for testing this might work.

I'm still busy with some things I need to finish asap, but hopefully can take a look at this in a few days.

EDIT: fixed syntax of pragma comment

[dougbinks]

I can't yet find a simple generic way to force the linker to always compile & link a runtime compiled class which is in a static library.

The only approach which appears to work is to ensure the definition of the class' constructor is in a header, and that this is included by the main project, and that this has #pragma comment(linker, "/include:" __FUNCDNAME__ ).