Re: [boost] [tools][bcp] using boost internally in other libraries

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-09-24 14:17:06

On Saturday 24 September 2005 12:51, David Abrahams wrote:
> bjorn_at_[hidden] writes:
> > On Saturday 24 September 2005 01:09, David Abrahams wrote:
> >> Bjørn Roald <bjorn_at_[hidden]> writes:

> >> > - configuration management issues in general for us and our customers
> >>
> >> Such as?
> >
> > mostly a concern if we have to maintain other brances of boost than the
> > library maintainers on boost.org.
>
> Ah.

I may have been a little quick here.  It really concerns me that I sell a
library were I have to send with it a description with a long list of
libraries-versions my customers configuration management will have to deal
with.  One of the items on the long list is me telling the
customers configuration manager to ensure that if they use boost directly or
indirectly through other libraries, they better use 1.32.0 compiled with the
following compiler std lib and options....  Configuration Nightmare -- and it
is assured to come back to me and haunt me.  My library may have to support
many versions of boost, with potential API changes.

Ideally the list should be empty, at least as short as possible.

>
> >> > - platform support in Boost ( or if the platform support Boost if you
> >> > like ;-)
> >>
> >> Sorry; what do you mean?
> >
> > Just trying to be funny, sorry...  the pun was that if boost is standard
> > conformant, then the platforms are to blame.   However, there are often
> > some truth in what I try to joke about.
>
> I understand, but I don't even understand the first part.  In what way is
> "platform support in Boost" a concern?

Sun compilers come to mind.  I have had to massage boost code every time I
used it with sun compilers.  And I have to admit I usually avoid trying :-(
I believe Steve Clamage of Sun recently announced that the Sun CC would be
boost compatible soon.   Anybody have an update on that?  I have not tried
with any of the newest versions of SunStudio and I don't believe they are in
the regression tests either.

Also, I believe ACE have a much longer bragging list when it comes to
platforms
supported.  I am not saying the portability is bad, just that it still may
be a concern for some.

> > Use of dlopen/dlsym and the win32 equallents is sertainly possible.  Good
> > point -- I will think more about that one.  This could be appropriate if
> > internal use of boost can be statically linked into a loadable library,
> > and that module's services can be accessed through simple methods,
> > alternatively through some framework - component hook-up.  Interfaces to
> > the module have to be Boost less.
>
> Yes.  I can even imagine a nice tool or library for wrapping these
> interfaces up into isolated components so you and your clients don't
> have to deal with the entry point/type erasure nitty-gritty.  That
> might be an excellent candidate for a Boost library that supports
> namespace renaming.

Funny, I have a colleague battering me about the same general idea in a
completely different context.  This is part of some work we do on a
component framework.  His approach was using some pretty advanced macro
stuff, and I am always skeptical to that, probably to skeptical some times.
He is a Java Guru really, and relatively new to C++.  He thought WOW
preprocessor -- powerful.  I am trying to moderate, and point at other
features in the language.  But there may be more to this, I need to pay more
attention :)

Are you thinking about connecting this to some sort of new library
abstraction
feature in form of a library?  And possibly combined with something
generating
code based on macros, templates or just some other tool/model/pattern?

How does this tie to work on the Boost Interface Library proposal?

>
> I just meant that we're probably fully committed to having ugly
> workarounds, at least in some parts of Boost, so what does one more
> hurt?

While cross country skiing in the Norwegian mountains we have a saying:
"It is
never too late to turn around".  It refers to the prospect of bad weather
ahead.

>
> > But I feel like you missed one important point I tried to make.
> > What I try to propose is something requiering no change in the way
> > boost source code is written or maintained.  I propose tool support
> > for a _production_step_ ensuring namespace renaming in a subset of
> > boost selected with the bcp tool.
>
> Yes, I noticed that.  It's a really neat idea, but I have no clue
> whether it's practical.  Actually I do at least have a _clue_.
> Depending on the level of PP usage in a Boost header, it could be very
> difficult to identify all the places that symbols need to be changed.
> And even then a naive "replace the boost identifier" strategem is not
> guaranteed to work unless we all maintain an agreement that "boost" is
> never to be used as an identifier other than for the outer boost
> namespace.  I'm not sure what other issues are lurking in there;
> these are just the two that popped into my head immediately.

Well you are right,  in the tests I have done I quickly I had to add special
treatment for "boost.org" in the license.  There will be more.

----
Bjørn