Steve Willer (willer@carolian.com) wrote:
| JdeBP@jba.co.uk (Jonathan de Boyne Pollard) wrote:
| >If you ask me, I think that auto_ptr is not ready for standardisation.  Let
| >the multiple different variants on auto_ptr be provided by third-party
| >libraries, and wait a few years to see what particular variant becomes
| >popular.  Then standardise that one.
|
| I don't much like that idea, myself. I'd prefer that compiler vendors
| not pollute my namespace with tiny classes like auto_ptr if they're not
| part of the standard library. I would prefer to be given the opportunity
| to put together what I prefer if they're not going to offer anything
| adequate in the standard.

There's no reason that the third-party libraries cannot use namespaces of
their own, which solves your pollution issue.

The important point is that std::auto_ptr *cannot* be replaced by user
code, whereas mylibrary::auto_ptr (for example) *can* be.  Looking at the
number of people in these threads who say things like "but you can always
replace auto_ptr by a class that does ...", it seems that having an auto_ptr
that is replaceable is highly desirable right now.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Willer (willer@carolian.com) wrote:
| JdeBP@jba.co.uk (Jonathan de Boyne Pollard) wrote:
| >Yes, with conditional compilation, and judicious use of typedefs, you could
| >get around this.
| >
| > #if defined(USE_DEBUGGING_AUTO_PTR)
| > typedef throw_exception_auto_ptr my_auto_ptr ;
| > #else
| > typedef std::auto_ptr my_auto_ptr ;
| > #endif
|
| Perhaps
|
| #ifdef USE_DEBUGGING_AUTO_PTR
| # define auto_ptr throw_exception_auto_ptr
| #endif

No.  That code is disallowed by [lib.macro.names] which prohibits you from
defining a macro for auto_ptr if the translation unit includes <memory>.

( Interesting note : this restriction is not qualified by the relative
order in which you define the macro and include the header.  It is
absolute. )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4popnk$mio@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:

> The important point is that std::auto_ptr *cannot* be replaced by user
> code, whereas mylibrary::auto_ptr (for example) *can* be.  Looking at the
> number of people in these threads who say things like "but you can always
> replace auto_ptr by a class that does ...", it seems that having an auto_ptr
> that is replaceable is highly desirable right now.

I don't understand the point about std::auto_ptr not being replaceable.

// file1.c
#include <memory>
using std::auto_ptr;
...

// file2.c
#include <memory>
using other_library::auto_ptr;
...

You just need to change that using declaration at the top of the file.
If you like, you can even use a macro or a namespace alias.

--
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]