🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #4123

Re: auto_ptr problems

#4123
From: Nathan Myers ncm
Date: Sun, 21 Apr 1996 06:57
51 lines
3191 bytes
Fergus Henderson wrote:
> 
> In comp.lang.c++.moderated, kanze@gabi-soft.fr (J. Kanze) writes:
> 
> >"Nathan Myers" <ncm@cantrip.org> writes:
> >
> >|> The Draft standard requires that your compiler not try to generate
> >|> auto_ptr::operator->() unless you use it.
> [...]
> >The requirement in the draft that Nathan is referring to (and which *is*
> >new, and not supported by many compilers) is that they not check the
> >return type of operator-> *unless* they actual have to generate the
> >function.  (I'm not sure of the exact words, but that is more or less
> >the meaning.)
> 
> I'm sure you're right, but when I had a look for this in the draft
> standard, I couldn't find it.  Could anyone please direct me to the
> appropriate place?

Actually, the language is a lot broader than James suggests. The WP
places no restrictions on the return type of operator->, as such; it 
only defines the meaning of the expression -> in terms of that return 
type.  This implies that it is at the call site that an error has 
occurred, if you try to apply "a->b" where a.operator->() returns 
something that doesn't have a member b. 

(In fact, it doesn't say that, if you do use it, it needs to return
a pointer.  That is, if X::operator->() returned a Y&, and Y defines
Y::operator->(), then x->m could mean x.operator->().operator->m.
I don't know of any compilers that support this (yet).)

The language in the post-Santa Cruz mailing is in 14.7.1, paragraph 6:
"An implementation shall not implicitly instantiate a ... non-virtual
member function ... that does not require instantiation."

Many current compilers generate the code for all member functions when
the class is instantiated, and then report an error if some unused member
uses an operation not defined for the template argument instantiated on.

So if your compiler doesn't support auto_ptr<int>::operator->(), it's
broken on several counts even before we start talking about template
constructors.  But that's life before the Standard.

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/
---
[ 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                             ]
Technical Details
Message-ID: <3179534C.508B295B@cantrip.org>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <4l0uib$snf@netlab.cs.rpi.edu> <4l3ujn$cl5@netlab.cs.rpi.edu> <4l86m8$s53@netlab.cs.rpi.edu> <4l9vb5$665@mulga.cs.mu.OZ.AU>

Show Full Headers
Complete Article Headers
From: "Nathan Myers <ncm@cantrip.org>" <ncm@cantrip.org>
Message-ID: <3179534C.508B295B@cantrip.org>
X-Original-Date: Sat, 20 Apr 1996 14:12:44 -0700
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 21 Apr 96 06:57:08 GMT
Approved: fjh@cs.mu.oz.au
Newsgroups: comp.std.c++
Subject: Re: auto_ptr problems
Organization: Best Internet Communications
References: <4l0uib$snf@netlab.cs.rpi.edu> <4l3ujn$cl5@netlab.cs.rpi.edu> <4l86m8$s53@netlab.cs.rpi.edu> <4l9vb5$665@mulga.cs.mu.OZ.AU>
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i386)
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMXncWuEDnX0m9pzZAQHBEAF/eCxdJI4dyTORNo5pLN6x/3HE9O1Ors12
 kHmILiUGCEnLlgJ0qUCzZ9HLqIWpIkij
 =nfVW