Boost BCP namespace renaming : dispelling the FUD ?
Hi, When implementing a library, one might want to neither require nor prevent the library users to also use any version of Boost. I believed that BCP used with namespace renaming would allow the use of (namespace-renamed) Boost in the implementation of such a library without *any* concern about conflict at link time and / or rub-time errors if the library user chooses to also use another Boost version. However, I have been reading that Boost brings some symbols that cannot be renamed because they are out of any namespace, with "C" linkage[*]. This brings the following questions : 1) can a list all such names be found ? 2) To be *completely safe*, must I : 2.1) only avoid using those symbols in my library 2.2) avoid the boost libaries that provide such symbols 2.3) avoid boost libraries that depend on such symbols (how am I to find out which ?) 2.4) avoid boost libraries that depend on the boost libraries providing such symbols (easier to do than 2.3 with bcp, I believe). 2.5) Despair ! (i.e. forgo boost usage under such constraints). Boost is a great set of libraries, I think that it is a pity that a legitimate concern (not imposing a specific Boost version on users) would prevent it's use for implementing libraries : please, help me dispel the Fear, Uncertainty and Doubt over this use case ! Best Regards, Bernard [*] http://stackoverflow.com/questions/2907882/using-concurrently-2-versions-of-...
When implementing a library, one might want to neither require nor prevent the library users to also use any version of Boost.
I believed that BCP used with namespace renaming would allow the use of (namespace-renamed) Boost in the implementation of such a library without *any* concern about conflict at link time and / or rub-time errors if the library user chooses to also use another Boost version.
However, I have been reading that Boost brings some symbols that cannot be renamed because they are out of any namespace, with "C" linkage[*].
This brings the following questions :
1) can a list all such names be found ?
Well a quick grep for extern "C" would do it?
2) To be *completely safe*, must I : 2.1) only avoid using those symbols in my library 2.2) avoid the boost libaries that provide such symbols 2.3) avoid boost libraries that depend on such symbols (how am I to find out which ?) 2.4) avoid boost libraries that depend on the boost libraries providing such symbols (easier to do than 2.3 with bcp, I believe). 2.5) Despair ! (i.e. forgo boost usage under such constraints).
No need to dispair at all ;-) I changed bcp a while back to rename extern "C" functions that begin with a "boost_" prefix, and nagged library authors that weren't already doing so to make any extern "C" functions they were declaring to conform to that convention. So unless there have been any regressions, it should just plain work.... but let me know if it doesn't!! John.
Thank you very much for your answer (and of course, your work on BCP ! ).
John Maddock
When implementing a library, one might want to neither require nor prevent the library users to also use any version of Boost.
[...]
However, I have been reading that Boost brings some symbols that cannot be renamed because they are out of any namespace, with "C" linkage[*].
This brings the following questions :
1) can a list all such names be found ?
Well a quick grep for extern "C" would do it?
Well, my grep-foo only got me so far as to find the 53 files, but I believe 'd have to parse those to get the names inside the multiline "{}". Anyway, they all are only in a dozen libraries.
2) To be *completely safe*, must I : 2.1) only avoid using those symbols in my library 2.2) avoid the boost libaries that provide such symbols 2.3) avoid boost libraries that depend on such symbols (how am I to find out which ?) 2.4) avoid boost libraries that depend on the boost libraries providing such symbols (easier to do than 2.3 with bcp, I believe). 2.5) Despair ! (i.e. forgo boost usage under such constraints).
No need to dispair at all
I changed bcp a while back to rename extern "C" functions that begin with a "boost_" prefix, and nagged library authors that weren't already doing so to make any extern "C" functions they were declaring to conform to that convention.
Thank you very much for this work. It believe it is very important to overcome the reluctance to use Boost when developping libraries. The misconception that it cannot be safely done is still very widespread and dispelling would deserve a clear statement that such usage is indeed supported. It is unfortunately not obvious as one currently has to guess it from the BCP documentation (and would-be users might not even realize that BCP is indeed the tool fit for such a use case !).
So unless there have been any regressions, it should just plain work.... but let me know if it doesn't!!
Thank you very much, I'll give it a try ! Best Regards, Bernard
participants (2)
-
BernardH -
John Maddock