Interest in adding support for the Bloomberg Standard Library
Bloomberg has its own C++ standard library, BSL, which sits on top of another standard library but replaces containers with their own versions. The BSL containers are somewhat similar to Boost.Container's: they provide stateful allocators, as well as backport some C++11 extensions to C++03. Before I make all the necessary changes and do a pull request, I would like to make sure the Boost community would be ok in including support for this in Boost.Config. This library is fairly specific to one company and not used much elsewhere, despite being open-source (<https://github.com/bloomberg/bde>). We are also trying to phase out usage of this library with the 'std' namespace (it can be configured to use the 'bsl' namespace instead), but that's likely not going to happen anytime soon. As part as providing support for this in Boost, we would also be providing testers, mostly on big iron unix (AIX-powerpc, SunOS-sparc). Any interest?
On 8/27/15 1:40 PM, Mathias Gaunard wrote:
Bloomberg has its own C++ standard library, BSL, which sits on top of another standard library but replaces containers with their own versions. The BSL containers are somewhat similar to Boost.Container's: they provide stateful allocators, as well as backport some C++11 extensions to C++03.
Before I make all the necessary changes and do a pull request,
pull request for which library? This sounds like you'd like to incorporate BSL into Boost containers. Is that what you mean or something else? I would
like to make sure the Boost community would be ok in including support for this in Boost.Config.
Wouldn't it be more appropriate to make a Bloomberg.Config which would #include <boost/config.hpp> ?
This library is fairly specific to one company and not used much elsewhere, despite being open-source (<https://github.com/bloomberg/bde>). We are also trying to phase out usage of this library with the 'std' namespace (it can be configured to use the 'bsl' namespace instead), but that's likely not going to happen anytime soon.
I'm not sure how this is relevant to Boost
As part as providing support for this in Boost, we would also be providing testers, mostly on big iron unix (AIX-powerpc, SunOS-sparc).
Any interest?
Well there would certainly be interest in getting more testers. Also getting underway will be the "Boost Library Official Maintainer" program. Sounds like this could be of on interest to Bloomberg. We'll be presenting it at CPPCon. Since Bloomberg is a sponsor of CPPCon I'm assuming you or someone like you will be there to participate. So there might be something good in all this? Robert Ramey
On 27/08/2015 23:12, Robert Ramey wrote:
Before I make all the necessary changes and do a pull request,
pull request for which library? This sounds like you'd like to incorporate BSL into Boost containers. Is that what you mean or something else?
<snip/>
Wouldn't it be more appropriate to make a Bloomberg.Config which would #include <boost/config.hpp> ?
No, I'm talking about Boost supporting BSL as a C++ standard library provider, just like libstdc++, libc++, STLport, roguewave, etc. i.e. adding the option to boost/config/select_stdlib_config.hpp
Well there would certainly be interest in getting more testers.
The testers would be for the configuration with BSL as a standard library, in case that wasn't clear either.
On Fri, Aug 28, 2015 at 12:21 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 27/08/2015 23:12, Robert Ramey wrote:
Before I make all the necessary changes and do a pull request,
pull request for which library? This sounds like you'd like to incorporate BSL into Boost containers. Is that what you mean or something else?
<snip/>
Wouldn't it be more appropriate to make a Bloomberg.Config which would #include <boost/config.hpp> ?
No, I'm talking about Boost supporting BSL as a C++ standard library provider, just like libstdc++, libc++, STLport, roguewave, etc.
i.e. adding the option to boost/config/select_stdlib_config.hpp
Did you have a chance to test it with Boost locally? Or, if you have that knowledge, how compliant that implementation is? How many libraries other than Boost.Config and Boost.Container are going to be affected? I'm asking in order to assess how much trouble that might add to library maintenance.
Andrey Semashev <andrey.semashev <at> gmail.com> writes:
Did you have a chance to test it with Boost locally? Or, if you have that knowledge, how compliant that implementation is? How many libraries other than Boost.Config and Boost.Container are going to be affected?
It is fairly standards-compliant, unless you consider extensions (as-is additional overloads to a standard function) to be non-conforming. The problem is that it sits on top of another standard library, and inherits some of its bugs, but not all of them. Therefore anything detecting a particular standard library and working around bugs needs to be more careful. So long as the boost library author is using boost config feature macros, there should be no problem, but if he's directly trying to detect which standard library is being used, for example directly assuming that this is libc++ because _LIBCPP_VERSION is defined, it might fail. There is a small issue related to conformance: it requires strict aliasing to be disabled (-fno-strict-aliasing). I know that's a bit controversial, but it shouldn't affect anything at the source level.
participants (3)
-
Andrey Semashev -
Mathias Gaunard -
Robert Ramey