RE: [boost] plain pointers and shared_ptr

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-27 08:31:52

From: E. Gladyshev [mailto:egladysh_at_[hidden]]
> 
> > or even other languages.  The name mangling done by
> > your C++ compiler can 
> > prevent the DLL from being used by other C++
> > compilers or by other languages 
> > that can easily call "C" functions exported from
> > DLLs.
> 
> Even worse the name mangling is different
> even between different version of the same compiler.
> For instance if your switch from VC++ v5.0 to VC++
> v6.0
> you would have to rebuild all the DLL's in your
> company project.  Bur first you would have to
> make sure that all your teams have switched to VC++
> 6.0
> and all your consultants have done it as well. 
> If you got about 40 DLL subprojects supported
> by different teams, it is very painful.

This is certainly an issue.  Whenever your tools change, you must rebuild
everything, but how often does that occur?

> 1.  If an exported class is derived from a base class
> and the base class is changed you would have
> to rebuild the whole project most likely all teams
> will have to do that, even if the change is
> only affect the internal functinality of 
> the exported class.

If you use the Pimpl idiom, then all of the implementation, including data
members, is hidden in the DLL, and no client code must be recompiled.

> 2. In VC++ environment there are memory allocation
> problems if you are not using the DLL version of
> the C run-time library.  It is well documented
> by MS and others.  So you do have to ensure that
> all VC++ project settings are consistent
> for all teams in your company and for
> other companies that you are working with.

This is not a problem once configured correctly.  It is a known state to
which all projects must be set.  Once done, this is a non-issue.

> 3. There are problems with inline functions.
> Don't even dare to modify them without making
> all the teams to rebuild their components.

If you add an inline function, member or not, no existing client will be
using it, so there's no need to recompile anything.  If you change an
existing inline function, then of course you must recompile.  How is this a
problem with C++ DLLs?

> All these problems don't exist for C interfaces.

Sure they do, in their own way.

1. If you change the layout of a structure in C, then you'd better compile
all client code or havoc will ensue.  Otherwise, typically, C code is not
inlined (macros), so changes are hidden.  This is what the Pimpl idiom does
for C++ code.  It makes the class an opaque type.

2. C uses malloc() and free() which often interoperate just fine among
languages and DLLs.  However, as you pointed out in another message, you can
write your own global new and delete operators that all of your code uses
for heap allocations.

3. C doesn't have inline functions.  However, you can approximate them with
macros, and if you change a macro without recompiling client code, you have
the same problem as (3) above.

The point is that properly managed C++ code can work every bit as well as C
code (or at least extern "C" code) provided you have a common toolset for
all developers.

> My company tried to export C++ classes and we
> got about 40 DLL subprojects and some are 
> outsourced.  It is a nightmare...  Don't
> go down this road, it is not practical
> for real huge projects.

It is practical if you follow reasonable design guidelines and can mandate a
common C++ toolset.

Rob
Susquehanna International Group, LLP
http://www.sig.com