If someone doesn''t know, boost library has an "any" class that can be used as a type safe alternative to void*. The only problem is that it''s not exactly portable across dlls created with different compilers because it uses RTTI. I''m trying to find a good alternative... I''m implementing a state manager class. Something similar to Set/GetRenderState in D3D that takes a state as a first parameter and a value as a second. D3D, however, doesn''t take anything that''s more then 4 bytes so a LONG is good enough. I''d like to pass more complex data types. One alternative is boost::any, but as I mentioned it''s not portable across dlls compiled with different C++ compilers. I could simple pass a void* and a size of the buffer so the data would simply be copied and interpreted later on, but that''s not exactly type safe, plus it will involve allocating memory on the heap. Another alternative is to use a structure similar to COM''s VARIANT. The limitation of VARIANT is that only few data types can be passed. Also, later on I''d like to make my classes usable by scripting languages, so I have to keep that in mind. I''m kind of stuck... Can someone make any suggestions or give me some ideas? Any feedback is welcome. Thanks.

Well, this may be a silly question...

Why are you using multiple compilers?

Sometimes RTTI is closely associated with the name-mangling scheme of a compiler. If RTTI doesn''t work, then the name-mangling probably won''t either - in which case you can''t use C++ DLLs compiled using different compilers.

This is a bit of a rat''s nest as there is no definition to the standard on name-mangling or RTTI.

If you can use one compiler that is definately your best bet - for more reasons than just these ones. In which case you could use the boost::any class.

I have to say this again and again.

"C++ and dlls don''t mix well together. Dlls are designed and meant for C. If you must, use COM or recompile for each compiler. If you want total platform independence, you have to forgo dynamic loading totally."

Perhaps this should be sticky or in faq.

ummm. Void, COM uses DLLs.

I wrote my own component model library similar to COM only simpler. Works perfectly well across compilers.

quote:Original post by kill
ummm. Void, COM uses DLLs.

But COM enforces the format of the vtable and calling conventions so that you don''t have to worry about different compilers. Also, COM would make a scripting language really easy, because it supports reflection pretty much out of the box via the IDispatch interface.

If I had my way, I''d have all of you shot!

codeka.com - Just click it.

quote:
But COM enforces the format of the vtable and calling conventions so that you don''t have to worry about different compilers.

This is exactly why it''s so easy to implement COM components using C++ classes: any C++ compiler that supports COM has the same vtable layout.

quote:
Also, COM would make a scripting language really easy, because it supports reflection pretty much out of the box via the IDispatch interface.

It''s not really out of the box... You still have to implement all the dirty details of IDispatch. Type libraries make it easier but it''s still a pain...

quote:Sometimes RTTI is closely associated with the name-mangling scheme of a compiler. If RTTI doesn''t work, then the name-mangling probably won''t either - in which case you can''t use C++ DLLs compiled using different compilers.

quote:"C++ and dlls don''t mix well together. Dlls are designed and meant for C. If you must, use COM or recompile for each compiler. If you want total platform independence, you have to forgo dynamic loading totally."

That''s not quite correct. C++ and DLLs mix perfectly well together. You just have to keep in mind a few rules. Name-mangling can be disabled by using an extern "C" specifier. Class internals can be hidden from the interface of the DLL and a simple factory function can be used to construct all kinds of classes.

Total platform independence is also possible. Of course, just as you have to recompile a main program for different platforms, you''ll have to recompile your DLLs (or shared objects, or shared libraries or whatever).

Of course, the only drawback is that if you want to be independent of platform and compiler, you can''t use RTTI and exception handling... That''s sad, but for RTTI, a custom system isn''t difficult to implement. Exception handling on the other side can''t be implemented with other means, but it''s possible to live without them.

Here is an article on how to do Binary-compatible C++ Interfaces with DLLs.

quote:Original post by kill
It''s not really out of the box... You still have to implement all the dirty details of IDispatch. Type libraries make it easier but it''s still a pain...

That''s why I said almost out of the box. If you''re using ATL and only implement one interface, you do get it for free though.

If I had my way, I''d have all of you shot!

codeka.com - Just click it.