should <bits/unique_ptr.h> include <backward/auto_ptr.h>?

[Jonathan Wakely]

On 26 June 2012 00:19, Jonathan Wakely wrote:
> On 25 June 2012 23:54, Benjamin De Kosnik wrote:
>>> To avoid <locale> pulling in the whole of <memory> I only want to
>>> include unique_ptr.h, but that means I also need to include
>>> <backward/auto_ptr.h>.  If bits/unique_ptr.h included auto_ptr.h
>>> itself then we could just use unique_ptr.h elsewhere in the library
>>> more easily.
>>
>> Hmm. Can you detail why you need auto_ptr.h at all? I must be missing
>> something. I see there are no current includes of it in any bits
>> headers, which seems ideal.
>
> Both shared_ptr and unique_ptr have constructors taking an auto_ptr
> parameter, they just don't explicitly include the header because the
> usual way to use them is <memory> which includes auto_ptr.h before
> including shared_ptr.h or unique_ptr.h

Maybe we could improve things with a patch like this (completely
untested).  It should be equivalent for users who include <memory> but
would let us include bits/unique_ptr.h or bits/shared_ptr.h internally
without also pulling in auto_ptr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto_ptr.patch
Type: application/octet-stream
Size: 3450 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20120625/122f54f0/attachment.obj>