RE: [Boost-Users] Re: Re: boost::intrusive_ptr and Managed C++?

From: Ferdinand Prantl (ferdinand.prantl_at_[hidden])
Date: 2003-08-22 02:55:50

Hi Holger,

> -----Original Message-----
> From: Holger Grund [mailto:yg-boost-users_at_[hidden]] 
> Sent: Thursday, August 21, 2003 14:50
> To: boost-users_at_[hidden]
> Subject: [Boost-Users] Re: Re: boost::intrusive_ptr and Managed C++?
> 
> 
> "Ferdinand Prantl" <ferdinand.prantl_at_[hidden]> 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_at_[hidden]>
 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/