Boost logo

Boost :

Subject: Re: [boost] Foundational vs non-foundational libraries
From: Loïc Joly (loic.actarus.joly_at_[hidden])
Date: 2014-05-21 19:19:58

Le 21/05/2014 22:26, Peter Dimov a écrit :
> Loic Joly wrote:
>> Internally, some boost classes depend on boost::shared_ptr, not on
>> std::shared_ptr. I remember making a suggestion that on platform
>> supporting std::shared_ptr, boost::shared_ptr should be a simple
>> typedef to std::shared_ptr. It was rejected. As a consequence, it's
>> very hard not to indirectly include <boost/shared_ptr> when you
>> include any part of boost. Which create issues for people who only
>> want to use std::shared_ptr in their code.
> I understand why such a setup would be better for some (most) users.
> It would however preclude any further improvements to boost::shared_ptr.
> boost::shared_ptr now supports arrays, for example, and no current
> std::shared_ptr does that yet.

Agreed, but I have never in my life wanted a shared_ptr to an array...

Types such as shared_ptr are IMO crucial, because they are basic
vocabulary types, that are part of library interfaces, and allow
communication between different parts of the code. To me, the fact that
std::shared_ptr is in std, and therefore might be used as a common
vocabulary type by anyone anywhere has more value than any bells and
whistles that might be added to anywhere::shared_ptr.

I agree that we are not here yet. Many concurrent implementations of
shared pointers (some of them buggy) exist in many libraries. But I also
believe that if boost switched by default to std::shared_ptr, it would
give this class enough momentum to make it not only an ISO standard, but
also a de facto standard. And it would be a great boon to library

The possibility to work with an alternative shared_pointer is
interresting, mostly to make it evolve in the future, but I think this
is an experimental feature. It should not be enabled by default, just
like compiler experimental feature are useful, but are best disabled by
default and explicitly enabled by people who really want to experiment
with them.

>> If I proposed [a library / a patch for an existing library] for boost
>> that returned a std::shared_ptr, would it be accepted? I sincerly
>> don't know.
> I concede that you'll probably be asked to return a boost::shared_ptr
> instead.


Boost list run by bdawes at, gregod at, cpdaniel at, john at