on Fri Mar 23 2007, "Greg Herlihy" <greghe-AT-pacbell.net> wrote:

> So is (*a).m ever well-formed when *a is an int? At first it may
> appear that the answer would have to be "no". But C++ is a rich
> Standard, full of nuances and subtleties. As it turns out, there is a
> least counter-example:
>
>     typedef int Int;
>
>     int main ()
>     {
>         int * p = new int;
>
>         *p = 3;
>
>         (*p).~Int();
>         p->~Int();
>     }
>
> The same kind of explicit destructor call syntax is also legal within
> the context of a template instantiated with a type int (and in which
> case the typedef is not needed).
>
> So, despite initial appearances to the contrary, ConceptGCC has in
> fact implemented iterator requirements correctly in this case.

Oh. my. G*D!

That's really perverse.  But technically, I have to agree with you.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 3/22/07 2:37 PM, in article 4602F166.5EBB30AC@this.is.invalid,
"Niels Dekker - no return address" <noreply@this.is.invalid> wrote:

> When concepts become part of the language, should a user-defined
> iterator be required to always have an operator->()?
>
> ConceptGCC 4.1.1 alpha 5 tells me that a class does not meet the
> requirements of an iterator concept, if it does not have an
> operator->().  As a consequence, such a class would not be allowed as
> a template argument for an std algorithm that required iterators as
> arguments.
>
> It seems to me that an operator-> is not necessary if the value type
> of the iterator does not have any members.  E.g., if the value type is
> a built-in type.

According to table 89 (Iterator Requirements) in the latest draft of
the C++ Standard, for an iterator, a: a->m must be defined if (*a).m
is well-formed. So unless there exists an example of the latter syntax
when the iterator's dereferenced type is an int, then operator->()
would not have to be defined for that iterator type and your position
would appear to be correct.

So is (*a).m ever well-formed when *a is an int? At first it may
appear that the answer would have to be "no". But C++ is a rich
Standard, full of nuances and subtleties. As it turns out, there is a
least counter-example:

    typedef int Int;

    int main ()
    {
        int * p = new int;

        *p = 3;

        (*p).~Int();
        p->~Int();
    }

The same kind of explicit destructor call syntax is also legal within
the context of a template instantiated with a type int (and in which
case the typedef is not needed).

So, despite initial appearances to the contrary, ConceptGCC has in
fact implemented iterator requirements correctly in this case.

> But even if the value type *does* have members, will an std algorithm
> ever need to call the operator->() of the iterator?

The question is whether I, as a C++ programmer, have ever written code
that uses the -> operator with iterators and whether I would be
inclined to do so in the future. The answer is yes on both counts.
Moreover it wouldn't make much sense for me to use the ->() operator
with an iterator unless I was confident that a->m would be defined
whenever (*a).m is defined.

So it stands to reason that unless the Standard mandates support for
operator->() when the semantically equivalent dereferencing operation
is defined, then there would little point in the Standard even having
a ->() operator in C++ language at all - because few would venture to
use it.

Greg

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]