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

[Jonathan Wakely]

On 26 June 2012 00:51, Jonathan Wakely wrote:
> 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

Still untested but this version compiles at least, so is an
improvement on the last one ;)

It would probably be better to put the shared_ptr and unique_ptr
constructors in a separate file rather than just the end of
auto_ptr.h, but I'll test it like this and see if the idea works.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto_ptr.patch
Type: application/octet-stream
Size: 4936 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20120626/9445d461/attachment.obj>