Re: [boost] Foundational vs non-foundational libraries

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 
compatibility.

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.

---
Loïc