Hi Holger,
-----Original Message----- From: Holger Grund [mailto:yg-boost-users@gmane.org] Sent: Thursday, August 21, 2003 14:50 To: boost-users@yahoogroups.com Subject: [Boost-Users] Re: Re: boost::intrusive_ptr and Managed C++?
"Ferdinand Prantl" <ferdinand.prantl@ixos.de> wrote
The second option (as Holger says) is to make a simple facade to the c++ library (all you might use), which will not have templates (here smart pointers) on the interface, and to use this facade instead.
Did I say that? Anyway, I absolutely agree.
Oops, sorry, I thought a bit further... :-)
I just want to point out that IMHO the best solution is to _not_ export instrusive_ptr_add_ref and _release. If you do new and delete are called from different modules which works only if the same CRT instance is used. And that works only if both link against the exact same version of the CRT dll (that is both linking against a static CRT still yields to instances => two heaps => error).
The generally safest solution yes, but not always the simpliest and most understandable. With a pile of C++ libraries with templates and STL on interface to use, I would not be very keen on writing facades for each and every... Every such a wrapper also increases the complexity of the solution.
While we're at it, it's almost always a bad thing to export classes or functions that rely on classes from a DLL. DLLs are a run time concept. They don't have any clue which version of the compiler a consumer is built with.
E.g. say you export a function void foo( std::string& s ) { s = "Hello World!"; }
Oh yeah, that's terrible constraint - if releasing binary library, one must support more compilers and also create different binary names (e.g. boost_regex). It is not needed if you release sources of the library (not the case of commercial APIs). If STL is widely used in the dependency tree of libraries, it is a pity to abandon it from their interfaces, building special marshalling structures or serializing into streams or return pointers. In this situation I broke the general recommendation (no templates on iface), preferred simplier solution and went on with STL on interfaces. It is cheaper and runs faster too. I moved the task of creating a facade without STL to the person, who needs it. As long as everybody are happy with usage of the same STL on interface, such a facade does not need to be borned (for managed .net assemblies it is also not necessary)...
The DLL is built with the version A of the compiler and STL and the consuming application is built with version B. There is no guarantee for a binary compatibility between the two version. And indeed the code above will break if version 6 & 7 of VC are used (The former used a COW scheme while the second uses a short string optimization).
This must not happen. It is responsibility of the build configuration to use the belonging import libraries. It can be checked and forced by pragmas in msvc. Ferda
Also, do note that the DLL CRT now supports side by side sharing.
While I am in rant mode the catch(...) thing is also a very bad idea in VC. This currently catches (this will be fixed in 8.0) structured exception that are not C++ exception. That way serious error conditions are silently ignored.
-hg
------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/EbFolB/TM ---------------------------------------------------------------------~-> Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/