Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kill

boost::any, VARIANT, void* ...

This topic is 5813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
ummm. Void, COM uses DLLs.

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
quote:
Original post by kill
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.



This is not necessarily true.

the COM interface layout is identical to Microsoft''s vtable layout. The vtable layout, as far as I know, isn''t part of the c++ standard. Just the behavior of it is.

And remember, COM is completely Windows dependent at the present time.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
When would you ever only implement one interface? (IUnknown?)
Or even just two interfaces is fairly uncommon.

Another approach to the any type is Discriminating Unions, see CUJ Aug02 (article by Andrie Alexandrescu)

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!