|
Boost : |
From: William Kempf (williamkempf_at_[hidden])
Date: 2002-03-26 10:09:18
>From: "Jeff Garland" <jeff_at_[hidden]>
>Reply-To: boost_at_[hidden]
>To: <boost_at_[hidden]>
>Subject: RE: [boost] plain pointers and shared_ptr
>Date: Tue, 26 Mar 2002 07:37:53 -0700
>
> > > I don't think that it is pretty rare. If you worked
> > > on huge and multi-team projects, then I am sure
> > > you know that inter-module API's are specified
> > > in C much more often than in C++. It is especially
> >
> > Not at all. Perhaps in your environment, that is the case, but there
>are
> > many projects that are strictly C++.
> >
> > > important if the project has many DLL's or some of
> > > the client code has to be C.
> > > It is never a wise solution to export C++
> > > classes from DLL's (remember name mangling...etc.)
> >
> > Since when? I used to do it frequently and I know the developers here
>that
> > do NT work do it.
> >
> > > Let's get practical :).
> >
> > What's impractical about using strictly C++?
> >
>
>I have to back up Robert here. I've worked on a number of large,
>multi-team,
>C++ only projects that use DLL's extensively. I've seen these both on
>Windows
>and Unix. It works beautifully.
Playing devils advocate, it doesn't always work beautifully. The biggest
problem occurs when the libraries produced must be usable by other compilers
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.
Other than that, though, you can use C++ in DLLs very effectively. In fact,
many Windows programmers generate and use MFC extension DLLs on a daily
basis.
All that said, none of this really changes the problem domain. There simply
isn't a universal solution for what the poster wants.
Bill Kempf
williamkempf_at_[hidden]
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk