From -6741170707182110123 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a0fcd8899dc05427 X-Google-Attributes: gidf78e5,public From: willer@carolian.com (Steve Willer) Subject: Re: Implicit smart-to-dumb pointer conversions Date: 1996/06/12 Message-ID: <31bf3c49.114352119@sqarc.sq.com>#1/1 X-Deja-AN: 159840392 x-lines: 30 sender: news@sq.com (News Administrator) references: <009A31CF34AEC020.4980D61E@ittpub.nl> <4ottpt$4i4@kelly.teleport.com> <4pihj9$bd8@news2.delphi.com> <4pm8e7$55m@silver.jba.co.uk> content-length: 1073 organization: Carolian Systems, Toronto ON newsgroups: comp.std.c++ originator: clamage@taumet 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 ....would be simpler. This code would have to be included after , but that doesn't seem like a big deal to me. >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. [ 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 ]