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

From: John Maddock (john_at_[hidden])
Date: 2005-09-24 07:34:37

> in addition, a macro based solution will not work well in a
> side-by-side header setting.  The macros would expand to the same
> string when used in application.  Hence different definitions of
> types would be used internally in the library from those in the API
> in context of the application.
>
> My main concern in my original post was support for side-by-side
> binaries. However if a relatively drastic solution is needed, we
> should consider side-by-side header support as well.  To me it does
> not look like the macro solution support that.

Correct.
>> Is that an acceptable alternative?  It could be boilerplated inside
>> the Boost.Config system if necessary.
>
> For side-by-side binaries that is fine, but not for side-by-side
> headers.  But again, I could live with that.  Side-by-side headers
> would however be nice to many, I think.  If they really had different
> symbols in headers while compiling code using MyLib boost types could
> safely be used in API.  How to deal with possible need for type
> convertion for types used in API, e.g. between
> Mylib::boost::filesystem::path and boost::filesystem::path, would
> then be a problem that the user of MyLib could handle in a variety of
> ways.

Understood.

> An interresting thing I come to realize now is that my choice to look
> at a search replace strategy partly come from an interrest in not
> excluding posibility of using boost types in API.  I think my
> preference would be not to use them to avoid symbol
> incompatibillities.  But if they are in a different namespace they
> are no longer the boost types, or are they?

Correct.

There is one important use case for side by side headers though: where you 
want a private member of the class to be a boost type.  An obvious example 
would be using a boost smart pointer to implement the PIMPL idiom.

If a type is to be part of the API then the choices are:

1) Roll your own type with your own interface.
2) Roll your own implementation using the Boost (or TR1/2 interface).
3) Use the Boost implementation in your own namespace.
4) Use the Boost implementation as is.

Option (2) leverages the familiarity that using an established interface 
brings, option (3) is effectively the same thing, but may introduce an 
ambiguity about who is responsible for the maintenance of that component, on 
the other hand Boost components are very widely used and tested, so may be a 
safer bet than a "new" implementation.  Option (4) may be the ideal, but 
only if your library is Open Source (in the broadest possible meaning: in 
this case as long as the user can recompile with a Boost version of their 
choice).

Just thinking out loud really...

John.