Boost logo

Boost Users :

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


> 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
> Free s/h on orders $50 or more to the US & Canada.

Info: <>
Wiki: <>
Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at