First of all, STL is not part of the language, it''s just another API. Standard, but an API. It has very little to do with the language itself, just an API that uses the language facilities.
Second, what exactly do you mean you can''t have virtual members with the dll scheme? The virtual table implementation is standardized by COM. All self respecting C++ compilers support COM, which means you can safely have virtual members.
So, the only two features you can''t use is RTTI and exceptions, and these two aren''t used in C++ that often anyway. STL is not part of the language, and it should be exposed in the interfaces anyway. Any iterface that explicitly exposes an STL container is IMO a poorly designed interface.
boost::any, VARIANT, void* ...
quote:Original post by kill
Second, what exactly do you mean you can''t have virtual members with the dll scheme? The virtual table implementation is standardized by COM. All self respecting C++ compilers support COM, which means you can safely have virtual members.
You can''t do this and expect the dll to work on another compiler.
__declspec(dllexport) class C
{
public:
virtual void Method(); // implementation in dll
}
COM is a different story. It is an implementation specification that works only on win32. It uses really ugly macros to bypass the vtable. From what I can see from the macros, it is essentially doing some vtable calculations to turn the C++ calls into extern C methods.
quote:
So, the only two features you can''t use is RTTI and exceptions, and these two aren''t used in C++ that often anyway.
Says who? You are talking about programs using C++ as a better C only.
Programs who neglect exception safety are
1. not robust. Leaks resource/memory during a crash, assertion failure...ie. when something exceptional occurs.
2. Harder to maintain as error checking using return value gets messy. Usually these programs neglect error checking too.
Why do you think many programs nowadays (esp windows) have security problems like buffer overflow, crashes when error etc.
quote:COM is a different story. It is an implementation specification that works only on win32.
No it doesn''t. COM exists on a variety of platforms, including most UNIXes.
quote:It uses really ugly macros to bypass the vtable.
The COM headers have macros that either construct a v-table with proper v-table lookups (for use with C++), or a set of structs that match the v-table (for use with C). They don''t bypass the v-table.
quote:From what I can see from the macros, it is essentially doing some vtable calculations to turn the C++ calls into extern C methods.
No. The COM classes are proper C++ classes with proper v-tables. What the macros do is to describe equivalent structs so that COM interfaces can be used through straight C. Why you''d want to, I don''t know.
quote:Original post by DrPizza
No it doesn''t. COM exists on a variety of platforms, including most UNIXes.
Oh. I''m quite unaware of that. But if one can generate the proper macros/tools for the compiler, I''m pretty sure there''s no reason why it can''t be done. After all, the implementation doesn''t need use any platform specific libraries.
quote:The COM headers have macros that either construct a v-table with proper v-table lookups (for use with C++), or a set of structs that match the v-table (for use with C). They don''t bypass the v-table.
Bypass is a wrong word to use. What I meant was the macros implements a vtable type lookup table in C style, which is normally done behind the scene in the C++ compiler.
quote:No. The COM classes are proper C++ classes with proper v-tables. What the macros do is to describe equivalent structs so that COM interfaces can be used through straight C. Why you''d want to, I don''t know.
That''s the only way you can get platform/compiler independence - by specifying vtable layout and avoid C++ name mangling = C way.
If you don''t think that''s ugly, frankly I don''t know what is.
quote:Original post by Void
That''s the only way you can get platform/compiler independence - by specifying vtable layout and avoid C++ name mangling = C way.
As long as you''re using MSVC++, you don''t need those macros at all. They''re there so you can access COM from C, or from a non-Microsoft compiler (COM''s vtable is exactly the same as Microsoft''s compiler''s C++ vtable).
Don''t forget that COM is not only meant for C++, but also from VB, Pascal, Cobol, and basically any other language you can think of.
If I had my way, I''d have all of you shot!
codeka.com - Just click it.This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement