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.