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?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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                             ]

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                             ]

In article <3179534C.508B295B@cantrip.org> "Nathan Myers
<ncm@cantrip.org>" <ncm@cantrip.org> writes:

|> 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.

Now I'm getting confused.  In the ARM, it states (section 13.4.6):
"... It follows that operator->() must return either a pointer to a
cloass or an object of or a reference to a class for which operator->()
is defined."  I believe that many (most, all?) compilers have
interpreted this to be a semantic constraint on the declared return type
of the operator->() function.  My impression (admittedly very vague) was
that this was what all the noise was about; at the least, a user must be
able to declare a template with an operator->() returning e.g. T*, and
not get an error if the function is not used, even in the case in which
T==int.

Rereading the ARM, it is not at all clear that this was meant to be a
semantic constraint.  The general tone of the paragraph suggests rather
that this rule is a simple consequence of the semantics of operator->,
and not a rule in itself.  In this interpretation, I could not only
declare such a function, but even define it (template or no) and maybe
even call it explicitly ("p->operator->()").

Anyway, I think we are all agreed as to what is needed here, and that
the current draft fulfills that need.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ 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                             ]