On 10/12/2016 7:09 PM, Vinnie Falco wrote:

On Wed, Oct 12, 2016 at 6:58 PM, Edward Diener wrote:

...

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You: ... 2) Use std::shared_ptr

I would use std::shared_ptr and I'll answer the broader version of your question.

For my libraries, I assume C++11. Its too much work to try to support older compilers. There are so many features and advantages to having C++11 as the minimum language support that it is a very logical choice to require it.

Your assumption, of course is that any C++11 compiler implementation supports std::shared_ptr. Fair enough. Thanks !

On 10/12/2016 7:17 PM, Stefan Seefeld wrote:

On 12.10.2016 18:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You:

1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead

I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

At this point in time (with GCC 6.2 as my default compiler in my development environment), I'd use std::shared_ptr, and fall back to boost::shared_ptr for environments without C++11 support.

How would you fall back to support boost::shared_ptr ?

(In practice it's often the other way around. Consider Boost.Python: it has been supporting boost::shared_ptr for a long time, and I just now managed to add support for std::shared_ptr. I expect to eventually deprecate support for boost::shared_ptr, but that will still take a few years.)

So your interface(s) need to support both in the meantime ?

On 10/12/2016 8:40 PM, Stefan Seefeld wrote:

On 12.10.2016 20:20, Edward Diener wrote:

...

On 10/12/2016 7:17 PM, Stefan Seefeld wrote:

...

At this point in time (with GCC 6.2 as my default compiler in my development environment), I'd use std::shared_ptr, and fall back to boost::shared_ptr for environments without C++11 support.

How would you fall back to support boost::shared_ptr ?

With something as simple as:

#if __cplusplus >= 201103L // use std::shared_ptr ... #else // use boost::shared_ptr ... #endif

Wouldn't you need to duplicate the above every time you are using shared pointers ?

...

...

(In practice it's often the other way around. Consider Boost.Python: it has been supporting boost::shared_ptr for a long time, and I just now managed to add support for std::shared_ptr. I expect to eventually deprecate support for boost::shared_ptr, but that will still take a few years.)

So your interface(s) need to support both in the meantime ?

Yes.

OK, Thanks !

On 10/12/2016 9:29 PM, Stefan Seefeld wrote:

On 12.10.2016 21:19, Edward Diener wrote:

...

On 10/12/2016 8:40 PM, Stefan Seefeld wrote:

...

On 12.10.2016 20:20, Edward Diener wrote:

...

On 10/12/2016 7:17 PM, Stefan Seefeld wrote:

...

At this point in time (with GCC 6.2 as my default compiler in my development environment), I'd use std::shared_ptr, and fall back to boost::shared_ptr for environments without C++11 support.

How would you fall back to support boost::shared_ptr ?

With something as simple as:

#if __cplusplus >= 201103L // use std::shared_ptr ... #else // use boost::shared_ptr ... #endif

Wouldn't you need to duplicate the above every time you are using shared pointers ?

That depends on the granularity of the conditional block (something between conditionalizing a single token and including an entire header). What works best depends on the specific context.

In Boost.Python there aren't that many places in need of conditionalizing. Most code is so generic it doesn't even know or care whether it's passing shared pointers around.

OK, Thanks for the explanation.

Stefan

On 10/12/2016 8:06 PM, Gavin Lambert wrote:

On 13/10/2016 11:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You:

1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead

I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose.

If I'm writing a small library/program that doesn't need Boost for something else, then I'll use std::shared_ptr.

Are you assuming that programmers using your small library compiler with c++11 support ?

Otherwise, I'll use boost::shared_ptr, except where required to use std::shared_ptr by existing interfaces.

So if existing interfaces already used std::shared_ptr you'd keep them like that, else for any new shared pointer interfaces you would use boost::shared_ptr ?

(Why? Because boost::shared_ptr is better. It has shared_from_raw and a few other such convenience features.)

On 10/12/2016 9:09 PM, Gavin Lambert wrote:

On 13/10/2016 13:24, Edward Diener wrote:

...

Are you assuming that programmers using your small library compiler with c++11 support ?

Mostly I'm writing apps, or libraries for use within my organisation, not really for public consumption. So based on the intended target app/environment I already know whether it supports C++11 or not and can pick accordingly.

Perhaps I'm not the intended audience of your question in that regard. :)

I was just asking as a general question to see what others do. Any answers regarding your choice is interesting and valuable to me.

Not so much with shared_ptr (since boost::shared_ptr is a reasonable default for the dual case anyway), but in some cases where something needs to be used in both environments I'll put in some custom redirection eg:

#if some_detection_magic #include <atomic> namespace my_atomic { using std::atomic; } #elif some_other_detection_magic #include namespace my_atomic { using boost::atomic; } #elif some_fallback_is_available ... some custom implementation ... #else #error Cannot find an atomic implementation. #endif

Yes, this I understand. My cxx_dual library basically does the above but in a syntactically smoother manner, while assuming that the Boost side is always available so no "Cannot find an atomic implementation" will ever occur there.

And then my code will use only my_atomic::atomic instead. Obviously this is ABI incompatible whenever the magic detects differently, so it makes it harder to provide pre-built binaries, but it's great for source compatibility.

Understood.

In fact half the time I wonder if I should refactor code so that it never uses the std:: or boost:: namespaces directly and always import things into custom namespaces like this, such that it's trivial to swap out all uses of a given type with an alternate implementation, either from a separate library or with a custom wrapper. (Sometimes I have moments where I want to swap a custom allocator into all std::vectors, for example, which is easier if everything actually uses a custom typedef/alias.)

A namespace alias also works nicely. That's what cxx_dual uses. It's also much easier to encode into the process of dual implementations.

Haven't quite gone that far yet myself though, though I know that your cxx_dual library and Niall's similar library are along those lines.

The impetus for cxx_dual is that I was ( and still am ) working on a library where shared pointers and function callables are part of some public interfaces. So I was trying to decide, do I use boost::shared_ptr or std::shared_ptr, do I use boost::function or std::function ? And I had some answers, but whatever it was I felt I was sure to run into a potential end-user of my library who would feel, based on his compiler implementation, compiler support for C++11, compiler options, OS for which he was using my library, that whatever I chose would be wrong for him. Of course like most programmers I could simply say, these are my choices and if they don't correspond to what you are otherwise using if you use my library, it is up to you to adjust. My OP is an effort to see how other programmers involved with Boost think about this.

...

...

Otherwise, I'll use boost::shared_ptr, except where required to use std::shared_ptr by existing interfaces.

So if existing interfaces already used std::shared_ptr you'd keep them like that, else for any new shared pointer interfaces you would use boost::shared_ptr ?

If my code depends on something that uses std::shared_ptr then of course I'll use std::shared_ptr in the downwards-facing interfaces with that. But I will prefer boost::shared_ptr for any upwards-facing interfaces unless there's some compelling reason not to use it (such as not otherwise requiring a dependency on Boost).

The end-user of your library, especially if it is meant for public consumption, might find it odd <g> that some interfaces use std::shared_ptr and others use boost::shared_ptr. Even more so if he is using one or the other of the two consistently throughout his own usage of your library in whatever executable or library he is working on. But I understand why you would prefer your own way. As long as you document what should be used it is easy enough for the end-user of your library to adapt successfully.

On 10/12/2016 10:27 PM, Gavin Lambert wrote:

On 13/10/2016 15:04, Edward Diener wrote:

...

The end-user of your library, especially if it is meant for public consumption, might find it odd <g> that some interfaces use std::shared_ptr and others use boost::shared_ptr. Even more so if he is using one or the other of the two consistently throughout his own usage of your library in whatever executable or library he is working on. But I understand why you would prefer your own way. As long as you document what should be used it is easy enough for the end-user of your library to adapt successfully.

Typically I'll use a typedef in any public API anyway, such that consumers will just use FooPtr (or auto) and thus never need to type shared_ptr themselves.

Or I'll use a handle/body pimpl idiom so that the only shared_ptrs they see are the single private member of the handle type, and again they don't need to see them.

So in that regard, they shouldn't need to care which one I chose to use.

These are interesting ideas. Thanks !

On 10/13/2016 7:34 AM, Niall Douglas wrote:

On 12 Oct 2016 at 22:04, Edward Diener wrote:

...

...

Haven't quite gone that far yet myself though, though I know that your cxx_dual library and Niall's similar library are along those lines.

The impetus for cxx_dual is that I was ( and still am ) working on a library where shared pointers and function callables are part of some public interfaces. So I was trying to decide, do I use boost::shared_ptr or std::shared_ptr, do I use boost::function or std::function ? And I had some answers, but whatever it was I felt I was sure to run into a potential end-user of my library who would feel, based on his compiler implementation, compiler support for C++11, compiler options, OS for which he was using my library, that whatever I chose would be wrong for him. Of course like most programmers I could simply say, these are my choices and if they don't correspond to what you are otherwise using if you use my library, it is up to you to adjust. My OP is an effort to see how other programmers involved with Boost think about this.

Firstly Edward, you've done a really nice job with cxx_dual. Far more polished than my effort, which I effectively stopped work upon after it was clear after my C++ Now 2015 presentation of it showed there was little interest in such a facility from Boost people.

I appreciate the nice words.

I also am finding these responses very interesting, and thank you for asking the question, indeed you preempted me asking the same question. The responses confirmed my increasing suspicion that people are either rolling their own on the spot or else just assuming C++ 11. Not enough people want a formal framework for switching between STL 11 implementations.

Yes I agree with you. The lack of interest in even seeing what cxx_dual was about or trying it out, even when I attempted to make it as easy as possible for those who dislike seeing macros in their own code, does not really personally bother me since I write software for my own pleasure or practical use unless I am being paid to do it as a consultant. But it started me thinking about what other people do when they have to decide about using a Boost implementation of some library versus a C++ standard implementation of the same general library, since evidently cxx_dual is not the answer for them.

BindLib is now Boost-lite, and instead of focusing effort on providing code to shim between standards implementations I am now focusing effort on a new collection of standards aspiring C++ libraries based on the feedback yielded from the informal meetings I ran during CppCon 2016 (and which were minuted, and those minutes were distributed to those who attended). The new collection obviously includes all my own libraries, but I wouldn't recommend anyone else use it yet, it's too rough because it's using bleeding edge cmake and other tooling (e.g. it needs trunk LLVM 4.0) as well as bleeding edge C++ 17. I'm hoping to add a year of maturity to it first, and then open it up to anyone else who wants to add their libraries.

I should emphasise that Boost lite is not an alternative to Boost, more a staging ground for new libraries. A library should be able to coexist in both collections, and my aim is that Boost lite's many perhaps too bleeding edge facilities will greatly ease initial new C++ library development as a half way house to entering the Boost review queue and later entry into Boost. The idea is that the new tooling can automate a great deal of development tedium away, but the swap is that the C++ library has extremely strict requirements placed on exactly how it's organised and laid out to the extent that you'd have a lot of refactoring needed to bring in an existing library.

I personally believe that programmers will write libraries for C++11+ ( C++11, C++14, C++17 ) when the facilites of C++11+ are found to be useful for whatever programming may be needed for their library. I don't believe that any programmer can, or should, use whatever is the latest and greatest unless it provides an advantage for them. With that said any facility that makes it easier for programmers to write code that can be used by other programmers targeting C++11+ can be valuable. So go for it. I have always believed that a library targeted for C++11+ should be accepted into Boost if it is a worthy library, even if it cannot be used by programmers not compiling with C++11+. That has already happened with some Boost libraries and I see it as beneficial for showing what C++11+ can do.

On 10/13/2016 10:31 AM, Peter Dimov wrote:

Edward Diener wrote:

...

The lack of interest in even seeing what cxx_dual was about or trying it out, even when I attempted to make it as easy as possible for those who dislike seeing macros in their own code, does not really personally bother me since I write software for my own pleasure or practical use unless I am being paid to do it as a consultant.

The basic issue with a Boost library that allows one to switch between Boost and standard components is this: the usual motivation for using a standard component when available is to avoid a dependency on Boost. But if you don't have Boost, you also don't have the Boost library that would allow you to switch.

Good point ! I probably did not make the argument well enough that even when you have Boost you might prefer the C++ standard equivalent to avoid the Boost dependency. In other words, "having Boost" and "depending on Boost", for a particular library, are conceptually two different things, at least in my mind. Also the decision-making process in cxx_dual depends only on Boost Config. Other optional macro support in cxx_dual depends on PP and VMD. Tests depend on some other Boost libraries even when Boost is not chosen as a dual library. I can probably eleiminate the latter ( except for lightweight test ) if I want to.

On 2016-10-13 17:09, Vinnie Falco wrote:

On Thu, Oct 13, 2016 at 10:54 AM, Edward Diener wrote:

...

...even when you have Boost you might prefer the C++ standard equivalent to avoid the Boost dependency.

There is a greater cost to using Boost types over their C++ equivalent. They often differ in small ways. boost::optional, boost::posix_time, and boost::shared_ptr come to mind, there are others.

When writing code you can assume that a reader will know and understand C++ standard library types (since they are... standard). The same cannot be said about the corresponding Boost types. Admittedly this difference is sometimes slight but it is still present.

For this reason, a standard library type almost always has an advantage even when the Boost type offers improved functionality; standard library types are what all C++ programmers know.

Thanks Vinnie, you are writing much better I have been trying to write. I also see a bigger problem regarding the "bigger outlook". As a library maintainer of a boost library, would I rather have to support the boost type or the std type? It would be weird if my library would depend on std::posix_time but could not work with boost::posix_time. Sometimes, because of the subtle change in semantics, I have to choose one. Giving your argument I would choose std::posix_time which would make my own library semantically incompatible to boost. If I follow the ideal of "everything in boost should work together", then I would not fit well in the C++11 world any more. There was a while back a longer thread about having a "new" boost which cleans up on its old outdated libraries and I am now thinking that this here would be a rather good argument of doing such a change. In a first step one might say that everything in boost should work well with the std types (as long as there are no very good reasons not to do so), while the boost duplicates would become deprecated. In a subsequent change a boost/compat would be introduced with the sole purpose of adding support for libraries that are used in boost but are broken on compilers supported by boost (e.g. std::ref where it is broken). When all broken compilers are faded out, the compat part is removed so that at some point nothing is left. While this would introduce a lot of work, it would, in the long run free boost from the dilemma above. Best, Oswin

On Thu, 13 Oct 2016 at 10:32 Peter Dimov wrote:

Edward Diener wrote:

The basic issue with a Boost library that allows one to switch between Boost and standard components is this: the usual motivation for using a standard component when available is to avoid a dependency on Boost. But if you don't have Boost, you also don't have the Boost library that would allow you to switch.

There are two other motivations I've run into in the wild. a. To depend on less of boost for compile time reasons. The standard library equivalents on a given platform typically compile faster than the boost equivalents because they have less machinery thanks to only having to worry about a single platform. I say typically because it's not this simple since boost headers can be included in a more piecemeal fashion which can be used to optimize, but in practice, it holds. b. Some platforms don't have a boost implementation of things like threads, so its useful to be able to use the vendor supplied std versions in those cases. -- chris

On Thu, 13 Oct 2016 at 12:39 Edward Diener wrote:

You quoted me for the above but it should be Peter Dimov. I did author the OP.

Oops. Apologies. Thanks for the correction. -- chris

On 10/13/2016 4:21 AM, Oswin Krause wrote:

Hi,

On 2016-10-13 00:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You: [...] 2) Use std::shared_ptr

From my point of view, this is the best option and I would go so far as to say that this holds for almost all boost libraries that were included in c++11. My main argument is that it makes it easier for new projects to introduce boost, as it fits better into the c++11 environment. I agree that for most libraries, the boost version are a bit better or have a few more features, but for me this does not outweigh the cost of incompatbility with standard c++11 coding habits. I can not force a project to adopt all of boost even if they are only interested in a tiny fragment of it.

I gather then that your library is for programmers using C+11 on up.

Otherwise, if there are deep concerns about compatibility with boost, i would try to introduce a policy or simply use template arguments which just assume it is a shared_ptr of some kind.

In other words you would roll your own class template ?

Best, Oswin

On 13/10/2016 22:42, Oswin Krause wrote:

Well, prior to C++11 there is not such a question due to a lack of std::shared_ptr, so yes, solution 1) assumes C++11. For a new library I would take the route that is easiest to maintain in the years to come.

Actually std::tr1::shared_ptr or stdext::shared_ptr (variously) has been in many CRTs for many years before C++11. Though it didn't catch on as much.

On 10/13/16 12:14, Andrey Semashev wrote:

On 10/13/16 01:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You:

1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead

I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

Depends on the target. If I can rely on C++11 features being available in the project then I use std::shared_ptr. Otherwise I use boost::shared_ptr. Both times unconditionally, i.e. no auto-detection stuff.

I should also say that I find myself often using boost::intrusive_ptr instead of either std::shared_ptr or boost::shared_ptr but I'm not sure that's the answer you're looking for.

On 10/13/2016 5:14 AM, Andrey Semashev wrote:

On 10/13/16 01:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You:

1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead

I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

Depends on the target. If I can rely on C++11 features being available in the project then I use std::shared_ptr. Otherwise I use boost::shared_ptr. Both times unconditionally, i.e. no auto-detection stuff.

What would you do if the target is determined the general end-user, who may be compiling your library with whatever options he chooses with whatever compiler he chooses in whatever OS he chooses ?

On 10/13/2016 10:00 AM, Andrey Semashev wrote:

On 10/13/16 16:38, Edward Diener wrote:

...

On 10/13/2016 5:14 AM, Andrey Semashev wrote:

...

On 10/13/16 01:58, Edward Diener wrote:

...

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer.

You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You:

1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead

I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

Depends on the target. If I can rely on C++11 features being available in the project then I use std::shared_ptr. Otherwise I use boost::shared_ptr. Both times unconditionally, i.e. no auto-detection stuff.

What would you do if the target is determined the general end-user, who may be compiling your library with whatever options he chooses with whatever compiler he chooses in whatever OS he chooses ?

There is always a list of supported targets. If that list includes a target without C++11 then I'll probably use boost::shared_ptr. That is what I'm doing in Boost.Log, which supports C++03.

I understand that and I think that is the general consensus. But what might happen, not that it seems to bother anyone much but me <g>, is that your library, which supports C++03, is nevertheless "compiled" by some programmer(s) using C++11 in their own project. Then their normal use of std::shared_ptr ( because it's there and naturally supported by their compiler implementation in C++11 mode ) doesn't really "play well" with your own use of boost::shared_ptr. Of course you may well say "what's the big deal, when you interface with my library you will use boost::shared_ptr and have a dependency on it, while otherwise you have chosen to use std::shared_ptr and have a dependency on your compiler's implementation. I see no problem with that." And technically you would be right, but practically the user of your library might feel differently about it.

The choice is specific to a particular component, though. For instance, I tend to use Boost.Atomic even on C++11-enabled targets because I know it's potentially more efficient. I'm also reluctant to use std::condition_variable because I know some implementations have buggy timed functions.

Understood. One of the situations I discusses in my cxx_dual library, where a programmer provides a one-off override of his own use of a particular dual library, is based on exactly what you mention just above. I personally know for instance that the std::bind and std::ref implementations in VC++10 are broken, not that Microsoft will ever go back and fix them for a compiler that very few use anymore. My OP should have also posited that boost::shared_ptr and std::shared_ptr are presume to work equally flawlessly in my 'curiosity question".

On 10/13/2016 10:56 AM, Andrey Semashev wrote:

On 10/13/16 17:33, Edward Diener wrote:

...

On 10/13/2016 10:00 AM, Andrey Semashev wrote:

...

There is always a list of supported targets. If that list includes a target without C++11 then I'll probably use boost::shared_ptr. That is what I'm doing in Boost.Log, which supports C++03.

I understand that and I think that is the general consensus. But what might happen, not that it seems to bother anyone much but me <g>, is that your library, which supports C++03, is nevertheless "compiled" by some programmer(s) using C++11 in their own project. Then their normal use of std::shared_ptr ( because it's there and naturally supported by their compiler implementation in C++11 mode ) doesn't really "play well" with your own use of boost::shared_ptr. Of course you may well say "what's the big deal, when you interface with my library you will use boost::shared_ptr and have a dependency on it, while otherwise you have chosen to use std::shared_ptr and have a dependency on your compiler's implementation. I see no problem with that." And technically you would be right, but practically the user of your library might feel differently about it.

Well, that's a nuisance for the user, no doubt. But that's the consequence of the chosen balance between my burden as the library maintainer and user's convenience. Having configurable library interface can be a headache of itself, it doesn't look like a clear cut solution.

It is certainly easier just to make a choice and stay with it. I don't think that cxx_dual is a "headache" but of course I am biased, being the author. But it is good to know where you stand on this. Thanks !

On 10/13/2016 11:17 AM, Sylvester-Bradley, Gareth wrote:

On 13 October 2016 15:33, Edward Diener wrote:

...

I understand that and I think that is the general consensus. But what might happen, not that it seems to bother anyone much but me <g>, is that your library, which supports C++03, is nevertheless "compiled" by some programmer(s) using C++11 in their own project. Then their normal use of std::shared_ptr ( because it's there and naturally supported by their compiler implementation in C++11 mode ) doesn't really "play well" with your own use of boost::shared_ptr. Of course you may well say "what's the big deal, when you interface with my library you will use boost::shared_ptr and have a dependency on it, while otherwise you have chosen to use std::shared_ptr and have a dependency on your compiler's implementation. I see no problem with that." And technically you would be right, but practically the user of your library might feel differently about it.

I think you've summarised nicely how I feel about it - our need to support C++03 users while not making C++11 users uncomfortable.

We do it using-declarations in namespace bst (I pronounce it 'best'!), in headers called "bst/xxx.hpp", which default to symbols from std, but can be instructed to use Boost. No auto-detection. There's the ABI issue that Gavin Lambert mentioned earlier. Otherwise seems to work well for us. Sometimes (like bst::placeholders), there's a tiny bit of extra work to put the Boost names in the right places, but not often. We also sometimes switch a bunch of symbols together where that makes sense (e.g. having consistent std or boost function/thread/chrono). I agree with Peter Dimov that "bst" or "cxx_dual" would seem to live best outside of the main Boost distrib though.

It seems a bit onerous for you to do what's below for each Boost versus C++ standard library you want to work with. I also don't see below how you decide to define BST_XXX_BOOST or not for some XXX library, though I assume you have some mechanism, whether automatic or manual, that makes that decision. As far as cxx_dual it really only depends on Boost Config for its automated decision-making ability. I am not keen on duplicating the Boost Config functionality which cxx_dual uses, although I will look into whether or not it could be done easily enough. I tend to doubt it. The cxx_dual support macros for naming a non header-only library and testing for valid variants for a library do use Boost PP and Boost VMD. And of course the tests use other Boost libraries extensively, including of course lightweight test. Peter's objection to cxx_dual is well-founded, but I can't help thinking that the issue is not so much the Boost monolithic distribution actually existing on disk, but that using a Boost library creates at the very minimum header file dependencies at compile time and at the maximum dependencies on shared or static libs at run-time.

#ifndef BST_XXX_HPP #define BST_XXX_HPP #ifndef BST_XXX_BOOST #include <xxx> namespace bst { using std::xxx1; using std::xxx2; } #else namespace bst #include #include namespace bst { using boost::xxx1; using boost::xxx2; } #endif #endif

Cheers, Gareth

On 10/13/2016 12:50 PM, Sylvester-Bradley, Gareth wrote:

On 13 October 2016 17:18, Edward Diener wrote:

...

On 10/13/2016 11:17 AM, Sylvester-Bradley, Gareth wrote: <snip>

...

We do it using-declarations in namespace bst (I pronounce it 'best'!), in headers called "bst/xxx.hpp", which default to symbols from std, but can be instructed to use Boost. No auto-detection. There's the ABI issue that Gavin Lambert mentioned earlier. Otherwise seems to work well for us. Sometimes (like bst::placeholders), there's a tiny bit of extra work to put the Boost names in the right places, but not often. We also sometimes switch a bunch of symbols together where that makes sense (e.g. having consistent std or boost function/thread/chrono). I agree with Peter Dimov that "bst" or "cxx_dual" would seem to live best outside of the main Boost distrib though.

It seems a bit onerous for you to do what's below for each Boost versus C++ standard library you want to work with.

The namespace alias approach is simpler, obviously. But the advantage of using-declarations is we only bring in names we know are a good match, so you can't get suckered into taking advantage of something that wouldn't be available/equivalent in bst/cxxd namespace if you were building in the other mode. And like cxx_dual, we write it once and forget about it...

OK. But I don't know think that "suckered into taking advantage of something that wouldn't be available/equivalent" is much of a problem. Of course there may be differences between a Boost library and its C++ standard equivalent, but a programmer needs to understand what he is doing anyway when he programs a library and if he doesn't he shouldn't be tempted to use functionality which he does not understand completely. In cxx_dual you can also use using-declarations, rather than the automatic namespace alias, by using the low-level mod implementation header, but admittedly I do not explain how to do this and I appreciate that you have brought this up. I will add it to my documentation for cxx_dual.

The using-decl approach also has the advantage that we can solve problems like the placeholders. Not sure how many of these kind of things exist but it's certainly one issue. Your test has "using namespace cxxd_bind_ns::placeholders;" (https://github.com/eldiener/cxx_dual/blob/master/test/test_bind.cpp#L38). If you omitted this, and changed the uses of _1, _2, to cxxd_bind_ns::placeholders::_1, cxxd_bind_ns::placeholders::_2, I think you'd discover you've not mapped the Boost placeholders.

I agree that I did not map the placeholders for bind. I thought mapping the namespace was good enough. In general I fought against more than one namespace alias per mod in cxx_dual ( and correspondingly against more than one namespace macro per mod at the low-level ).

...

I also don't see below how you decide to define BST_XXX_BOOST or not for some XXX library, though I assume you have some mechanism, whether automatic or manual, that makes that decision.

No auto-detection. Default to std, manual decision to define BST_XXX_BOOST per-project/platform.

Doing it manually is fine but I think automatic should always be there for ease of use. Cxx_dual does automatic detection but then allows manual override macros to change it.

...

As far as cxx_dual it really only depends on Boost Config for its automated decision-making ability. I am not keen on duplicating the Boost Config functionality which cxx_dual uses, although I will look into whether or not it could be done easily enough. I tend to doubt it.

Agreed.

...

The cxx_dual support macros for naming a non header-only library and testing for valid variants for a library do use Boost PP and Boost VMD. And of course the tests use other Boost libraries extensively, including of course lightweight test.

(I also have a set of BST_TEST_XXX macros that map to Boost.Test or Google Test or Catch... but that's another e-mail thread!)

And I was raked over the coals for using macros <g> ! I am glad others are, like me, not afraid to use them.

...

Peter's objection to cxx_dual is well-founded, but I can't help thinking that the issue is not so much the Boost monolithic distribution actually existing on disk, but that using a Boost library creates at the very minimum header file dependencies at compile time and at the maximum dependencies on shared or static libs at run-time.

Basically agreed, but for C++11 users of our library, who only want to use bst/cxxd in std-mode, why should they have to have a Boost install at all?

Point taken. I am considering a stand-alone cxx_dual, but its reliance on Boost Config is a pretty big burden to overcome unless I incorporate much Boost Config logic in my own code, which I am not sanguine about doing. Boost Config is a magnificent achievement, without which cxx_dual does not exist. I acknowkledge that in the doc.

<snip>

Cheers, Gareth

On 10/13/2016 5:45 PM, Gavin Lambert wrote:

On 14/10/2016 06:46, Edward Diener wrote:

...

Point taken. I am considering a stand-alone cxx_dual, but its reliance on Boost Config is a pretty big burden to overcome unless I incorporate much Boost Config logic in my own code, which I am not sanguine about doing. Boost Config is a magnificent achievement, without which cxx_dual does not exist. I acknowkledge that in the doc.

Perhaps it's another argument for truly-modular Boost, where you can download individual libraries rather than a monolithic release.

There are many other arguments for what you suggest, not just cxx-dual. But without a versioning infrastructure, where each library has not only its own versioning information but can check if it is compatible with the versioning information of all its dependencies, I doubt it will succeed. Just randomly assuming that because Boost libary X depends on Boost library Y and the end-user places some release of Boost library X somewhere and some release of Boost library Y in the same "somewhere" directory structure where library X can find it, does not mean that Boost library X will work with Boost library Y.

I never really have any issues with including Boost code in desktop build environments, but it becomes a harder sell when writing embedded or cross-compiled code. (I usually still do it anyway, typically to plug holes in the libc, but it requires more justification.)

I have actually worked as a consultant for companies in programming groups, working on desktop applications and libraries, where the use of Boost was not considered, even for just header-only libraries, because the monolithic nature of the Boost distribution was not acceptable to the company. Many of these companies would rather spend literally millions of dollars rolling their own solutions, for which Boost already provided libraries that worked much better than anything that they could do. This is just dumb but this is how many companies for which I have worked as a consultant actually think. I don't think that the solution for cxx_dual, that it should not be part of a Boost distribution to be considered usable, is any more or less true of any other Boost library. But like you say if there were a workable modular Boost-like distribution of libraries cxx_dual would benefit from it like lots of other Boost libraries also would. While I understand Peter's point I do not think that it should mitigate against the ease of use of dual libraries in cxx_dual if that is what anybody really wants to do. However from asking my question and receiving your answer and others I can see that the problem which I have solved for myself in cxx_dual is not a problem at all for the large majority of library developers who have answered my OP.

On 30/10/2016 07:34, Edward Diener wrote:

What I gathered from my original OP from everyone's response is that either:

1) Programmers would rather hard-code a choice of using a Boost library or its C++ standard library equivalent in their code based on whether their code was meant to be used for C++11 or above or not

or

2) Roll their own hand-made system for choosing based on their individual needs

rather than use a library like cxx_dual which automatically makes the choice of whether to use a Boost library or its C++ standard equivalent based on what is available at compile time.

FWIW, I think that's mostly due to unfamiliarity with the library, and not an indication that more people wouldn't have used it had they been aware of it. Although as the std and Boost implementations are not identical in many respects, having code switch from one to another based on environment might make people nervous, unless they feel "in control" of the switching mechanism and can adjust its choices.

Hi Edward, On 29 October 2016 19:35, Edward Diener wrote:

On 10/13/2016 12:50 PM, Sylvester-Bradley, Gareth wrote:

...

Your test has "using namespace cxxd_bind_ns::placeholders;" (https://github.com/eldiener/cxx_dual/blob/master/test/test_bind.cpp#L38). If you omitted this, and changed the uses of _1, _2, to cxxd_bind_ns::placeholders::_1, cxxd_bind_ns::placeholders::_2, I think you'd discover you've not mapped the Boost placeholders.

As I originally replied I did not map the placeholders nested namespace for the bind dual library. But you are wrong in your assumption above. CXXD works perfectly well with the cxxd_bind_ns::placeholders::_n notation. There is no problem in C++ using a nested namespace for a namespace alias that is set to the namespace in which the nested namespace resides.

I knew that. But I didn't think Boost's placeholders were in boost::placeholders. They weren't as of 1.59.0, but it turns out I'd missed https://github.com/boostorg/bind/commit/db56733e4ed2125944b89e01cf36a9e451dd... So I'm sorry, I was out of date. Best regards, Gareth

Am 13.10.2016 um 20:01 schrieb Edward Diener:

On 10/13/2016 1:36 PM, Daniela Engert wrote:

...

Am 13.10.2016 um 00:58 schrieb Edward Diener:

...

...

4) Use neither, you roll your own shared pointer-like functionality

The last library that I designed also for use by external customers, I rolled my own 'handle' type which is completely opaque to users which see just a struct with no more than one single uintptr_t member. Under the covers it is a boost::intrusive_ptr. The idea is to prevent accidental misuse and not to force users taking a dependency on boost. The library itself is taking advantage of any boost functionality it sees fit.

OK, thanks ! I assume that actual implementation code for your opaque type is in the built portion of a non header-only library.

Exactly! These 'handles' refer to USB devices which may come and go. There's a 'weak handle' as well, which doesn't give access to a device but rather observes it's presence state and it's unique device instance name only. Users may construct handles only in the empty state, actual references to devices are handed out to client code by the library. And as long as there are any outstanding non-empty handles in client code, the DLL is kept locked in memory. Otherwise it may be unloaded from the process thereby freeing any remaining resources still lingering in the kernel's driver stack. Ciao Dani