In article <749713134snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>In article <rfgCEBnv8.5C2@netcom.com> rfg@netcom.com writes:
>
>>In article <749599908snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk
>> writes:
>>>We are discussing the standard here;  how the language *ought* to work (or
>>>alternatively ought not).
>>
>>We are discussing the standard here;  how the language *will be defined*
>>to work.
>
>Well, I was assuming that the language will be defined to work as it ought
>to work, rather than as it ought not to work.  ;-)

You have assumed too much.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCE5oqJ.7Co@netcom.com> rfg@netcom.com writes:

>In article <748860785snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk
> writes:
>>
>>    [example deleted]
>
>It seems that you have missed one important fact.  The problem you have
>noted is not in any way unique to "operator" functions.
>
>Suppose we have:
>
>        Class A { A (char*); };
>        A foobar (const A& a, const A& b);
>
>Six months later someone adds
>
>        Class B { B (char*); };
>        B foobar (const B& a, const B& b);
>
>Now does this new addition render the expression `foobar("abc","xyz")'
>"suddenly" ambiguous?  I believe that it does.

Except that there is a difference between "foobar" and "+".  One takes
precautions with function names to avoid name conflicts by avoiding names
that might be chosen by someone else.  One accepts the small chance that
this might cause problems.  The operator + is predefined and with a presumed
meaning, though that can be stretched on overloading.  For a built-in
operator operating on built-in types to change meaning depending on what
classes have been defined still seems insanitary.

As a slight variant of my previous post consider that at the same time as
Class B was added Class A was removed.  Then "abc"+"xyz" would silently
change its meaning.

>A few people have read the ARM, and concluded
>that this is the way the language is *already* defined to work.

We are discussing the standard here;  how the language *ought* to work (or
alternatively ought not).

--
John Hall     jfhall@avondale.demon.co.uk    CompuServe: 100016,1210

In article <189@davgar.arlington.va.us> david@davgar.arlington.va.us (David Garfield) writes:
>In article <rfgCE5oqJ.7Co@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>In article <748860785snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>>>
>>>    Class A { A (char*); };
>>>    A operator+ (const A& a, const A& b);
>>>
>>>If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.
>>
>>Nobody "suggested" anything.  A few people have read the ARM, and concluded
>>that this is the way the language is *already* defined to work.
>>
>>>Six months later someone adds:
>>>
>>>    Class B { B (char*); };
>>>    B operator+ (const B& a, const B& b);
>>>
>>>Perhaps A is String and B is DecimalInt.
>>>
>>>Suddenly the expression becomes ambiguous and existing code fails.  It may
>>>not fail all at once of course.  Each module will only fail as it uses a B
>>>and includes B.h.
>>
>>It seems that you have missed one important fact.  The problem you have
>>noted is not in any way unique to "operator" functions.
>>
>>Suppose we have:
>>
>> Class A { A (char*); };
>> A foobar (const A& a, const A& b);
>>
>>Six months later someone adds
>>
>> Class B { B (char*); };
>> B foobar (const B& a, const B& b);
>>
>>Now does this new addition render the expression `foobar("abc","xyz")'
>>"suddenly" ambiguous?  I believe that it does.
>
>Unfortunately, these situations are not comparable.

I think that they (obviously) are.

>Remember that there is, or may be, a conversion from a pointer
>to an integral type.

I haven't any idea what you are talking about here.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <749599908snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>In article <rfgCE5oqJ.7Co@netcom.com> rfg@netcom.com writes:
>>A few people have read the ARM, and concluded
>>that this is the way the language is *already* defined to work.
>
>We are discussing the standard here;  how the language *ought* to work (or
>alternatively ought not).

We are discussing the standard here;  how the language *will be defined*
to work.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCEBnGq.3Dy@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <189@davgar.arlington.va.us> david@davgar.arlington.va.us (David Garfield) writes:
>>In article <rfgCE5oqJ.7Co@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>>In article <748860785snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>>>>
>>>>    Class A { A (char*); };
>>>>    A operator+ (const A& a, const A& b);
>>>>
>>>>If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.
>>>
>>>Nobody "suggested" anything.  A few people have read the ARM, and concluded
>>>that this is the way the language is *already* defined to work.
>>>
>>>>Six months later someone adds:
>>>>
>>>>    Class B { B (char*); };
>>>>    B operator+ (const B& a, const B& b);
>>>>
>>>>Perhaps A is String and B is DecimalInt.
>>>>
>>>>Suddenly the expression becomes ambiguous and existing code fails.  It may
>>>>not fail all at once of course.  Each module will only fail as it uses a B
>>>>and includes B.h.
>>>
>>>It seems that you have missed one important fact.  The problem you have
>>>noted is not in any way unique to "operator" functions.
>>>
>>>Suppose we have:
>>>
>>> Class A { A (char*); };
>>> A foobar (const A& a, const A& b);
>>>
>>>Six months later someone adds
>>>
>>> Class B { B (char*); };
>>> B foobar (const B& a, const B& b);
>>>
>>>Now does this new addition render the expression `foobar("abc","xyz")'
>>>"suddenly" ambiguous?  I believe that it does.
>>
>>Unfortunately, these situations are not comparable.
>
>I think that they (obviously) are.

They are not comparible because, in this case, operator + has at least
these definitions:

    A operator+ (const A& a, const A& b);
    int operator +(int,int);
    double operator +(double, double);
    char *operator +(char *, int);
    char *operator +(int, char *);

Whereas your function foobar has this definition:

    A foobar (const A& a, const A& b);

The first is an overload and MUST CHOOSE a function.  The second is not an
overload, and there is no requirement to choose which function to use.
This makes the situtations not comparible.  If you wish, you can add a lot
of other function "foobar()"s, like operator + already has, and then see if
you can make foobar("abc","xyz") match A foobar (const A& a, const A& b);

Good luck.  I think you will need it.  :-)

>>Remember that there is, or may be, a conversion from a pointer
>>to an integral type.
>
>I haven't any idea what you are talking about here.

In ANSI C, you will find that a conversion from a pointer type to an
integral type (which one is not specified) MAY exist, and if it does it
must be reversible.  I have read in this group previously that the ARM
stipulates it MUST exist (I hope this changes).  This feature is, IMHO,
principally a leftover from the days when the "void *" type did not exist.
Thus, as I said, "there is, or may be, a conversion from a pointer to an
integral type."  This becomes important because "a"+"b" could be
interpreted in the example case as any of:

        int("a") + "b"
        "a" + int("b")
        A("a") + A("b")

Personally, I think the first two are better matches than the third, even
if they are basically meaningless.  And of course, there is no way to
choose between the first two, therefore we get an ambiguity.

>--
>
>-- Ronald F. Guilmette ------------------------------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

David Garfield
Email: david@davgar.arlington.va.us or david%davgar@uunet.uu.net or
       ...!uunet!davgar!david or garfield@verdi.sra.com

In article <rfgCEBnv8.5C2@netcom.com> rfg@netcom.com writes:

>In article <749599908snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk
> writes:
>>We are discussing the standard here;  how the language *ought* to work (or
>>alternatively ought not).
>
>We are discussing the standard here;  how the language *will be defined*
>to work.

Well, I was assuming that the language will be defined to work as it ought
to work, rather than as it ought not to work.  ;-)

I have no input to how it will be defined (other than here).  But I do have
an opinion on what it ought to do.  I accept that that opinion is only as
valid as the arguments and examples I can give.

--
John Hall     jfhall@avondale.demon.co.uk    CompuServe: 100016,1210

In article <283n1b$kjs@agate.berkeley.edu| hilfinger@CS.Berkeley.EDU writes:
|In article <280a9lINNf56@borg.cs.unc.edu>, leech@cs.unc.edu (Jon Leech) writes:
|> In article <2807oj$sks@agate.berkeley.edu>, hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
|> |>  [long quotes from ARM removed]
|> |> So, it appears that the ARM says, with no ambiguity at all, that
|> |> "aa" + "bb" is a perfectly legal expression.  Making this call illegal
|> |> would involve ADDING an additional restriction to the reference manual.
|>
|>     The additional restriction is already present. Section 5.7 says that
|> pointer addition is not an allowed type combination.
|>
|
|Good try, but now the baby has been thrown out with the bathwater.  Section
|5.7 says "The operands [of + and -] must be of arithmetic or pointer type."
....
|May I suggest that this passage and the entire section had better
|be a definition of the predefined operator+ functions only?

You suggest correctly.  The introduction to chapter 5 clearly states
that when operator overloading is performed, they follow syntax, but
that the requirements on type, etc, are replaced by the rules for
function call.  The first page of Chapter 5, in my copy of the ARM.

"...are replaced by the rules for function call....
 ...We repeat: the rules in this chapter do not cover expressions
 involving overloaded operators or user-defined conversion operators...."

rfg@netcom.com (Ronald F. Guilmette) writes:
: In article <749599908snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
: >
: >We are discussing the standard here;  how the language *ought* to work (or
: >alternatively ought not).
:
: We are discussing the standard here;  how the language *will be defined*
: to work.

It would be nice if the two would coincide.  But compatibility with
existing practice probably means that is too much to hope for :-)

--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

In article <748860785snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>
>    Class A { A (char*); };
>    A operator+ (const A& a, const A& b);
>
>If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.

Nobody "suggested" anything.  A few people have read the ARM, and concluded
that this is the way the language is *already* defined to work.

>Six months later someone adds:
>
>    Class B { B (char*); };
>    B operator+ (const B& a, const B& b);
>
>Perhaps A is String and B is DecimalInt.
>
>Suddenly the expression becomes ambiguous and existing code fails.  It may
>not fail all at once of course.  Each module will only fail as it uses a B
>and includes B.h.

It seems that you have missed one important fact.  The problem you have
noted is not in any way unique to "operator" functions.

Suppose we have:

 Class A { A (char*); };
 A foobar (const A& a, const A& b);

Six months later someone adds

 Class B { B (char*); };
 B foobar (const B& a, const B& b);

Now does this new addition render the expression `foobar("abc","xyz")'
"suddenly" ambiguous?  I believe that it does.

>This should keep full employment amongst maintenance
>programmers.  Is that the objective :-)?

You have a legitimate gripe, but it has nothing to do with overloading of
operators (in particular).  Rather, your gripe is a general one, and it
relates more directly to the whole idea of the implicit application of
user-defined type-conversions... a feature which, I would have to agree,
ought most definitely to insure full job security for C++ maintenance
programmers for quite some time to come.  (Why worry?  Be happy.  Become
a C++ maintenance programmer. :-)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCE5oqJ.7Co@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <748860785snz@avondale.demon.co.uk> Jfhall@avondale.demon.co.uk writes:
>>
>>    Class A { A (char*); };
>>    A operator+ (const A& a, const A& b);
>>
>>If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.
>
>Nobody "suggested" anything.  A few people have read the ARM, and concluded
>that this is the way the language is *already* defined to work.
>
>>Six months later someone adds:
>>
>>    Class B { B (char*); };
>>    B operator+ (const B& a, const B& b);
>>
>>Perhaps A is String and B is DecimalInt.
>>
>>Suddenly the expression becomes ambiguous and existing code fails.  It may
>>not fail all at once of course.  Each module will only fail as it uses a B
>>and includes B.h.
>
>It seems that you have missed one important fact.  The problem you have
>noted is not in any way unique to "operator" functions.
>
>Suppose we have:
>
> Class A { A (char*); };
> A foobar (const A& a, const A& b);
>
>Six months later someone adds
>
> Class B { B (char*); };
> B foobar (const B& a, const B& b);
>
>Now does this new addition render the expression `foobar("abc","xyz")'
>"suddenly" ambiguous?  I believe that it does.

Unfortunately, these situations are not comparable.  operator + already
has the following additional definitions, or something like these:
        int operator +(int, int);
        long operator +(long, long);
        unsigned int operator +(unsigned int, unsigned int);
        unsigned long operator +(unsigned long, unsigned long);
        char *operator +(char *, long);
        char *operator +(long, char *);
        any_type *operator +(any_type *, long);
        any_type *operator +(long, any_type *);

Now, do you really believe that
        A operator+ (const A& a, const A& b);
is demonstrably the "best" match for "aa" + "bb"?

Remember that there is, or may be, a conversion from a pointer
to an integral type.

[...]
>
>-- Ronald F. Guilmette ------------------------------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

David Garfield6
Email: david@davgar.arlington.va.us or david%davgar@uunet.uu.net or
       ...!uunet!davgar!david or garfield@verdi.sra.com

In article <KANZE.93Sep23152253@slsvhdt.us-es.sel.de> kanze@us-es.sel.de writes:

> [deleted]
>
>Several people have cited this passage.  But in fact, in the code in
>question, the operator function is 'String operator+( const String& ,
>const String& ).'  Both of the arguments are of class type.
>
>The question is: can the compiler apply user defined conversions to
>match such a function, when none of the parameters to the addition are
>of user defined types?
>
>Although there is nothing in the ARM to support this, or even to
>suggest that it is true, many compilers refuse to do it.  In the
>standards committee, it is at present under warm discussion, and I
>would not like to wager on the outcome.

Imagine:

    Class A {
 ...
 A (char*);
    }

    A operator+ (const A& a, const A& b);

If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.

Six months later someone adds:

    Class B {
 ...
 B (char*);
    }

    B operator+ (const B& a, const B& b);

Perhaps A is String and B is DecimalInt.

Suddenly the expression becomes ambiguous and existing code fails.  It may
not fail all at once of course.  Each module will only fail as it uses a B
and includes B.h.  This should keep full employment amongst maintenance
programmers.  Is that the objective :-)?

Surely this can never become valid.

PS:  What is "123"+"45"?  Is it the String "12345"?  Or is it the DecimalInt
"168"?

--
John Hall     jfhall@avondale.demon.co.uk    CompuServe: 100016,1210

In article <748860785snz@avondale.demon.co.uk>, jfhall@avondale.demon.co.uk (John Hall) writes:

> Surely this can never become valid.

[... referring to the expression "aa" + "bb" when there is a conversion
defined from char* to A.  ]

Let's get one thing straight: as far as I can see, it is not a
question of the expression BECOMING valid.  According to the ARM, it
very clearly IS valid, and it is therefore a question of it becoming
INvalid.  Numerous compilers don't accept it, but since compilers do
not define a language, one simply has to conclude that at the moment,
they are wrong.

Specifically, the ARM says

(1) "aa" + "bb" may be interpreted as the (ordinary infix function
    call) operator+("aa", "bb")  [NOTE: operator+ was NOT defined as a
    member function in this example.]  This reduces the problem to the
    case of ordinary calls of non-member functions. (Ref: ARM 13.4.2, 1st
    paragraph).

(2) A function call is legal if its arguments can be converted by
    a sequence of standard and user-defined conversions to the types
    of the formals and any ambiguities as to choice of function can
    be resolved.  Since there is no ambiguity in choice of functions
    here, this means that operator+("aa", "bb") is a legal call. (Ref:
    ARM 13.2).

So, it appears that the ARM says, with no ambiguity at all, that
"aa" + "bb" is a perfectly legal expression.  Making this call illegal
would involve ADDING an additional restriction to the reference
manual.

Now, it is an entirely separate matter whether the current state of
the ARM is DESIRABLE in this instance.  Personally, I've seen this
kind of argument before during the Ada standardization, and it always
seemed silly to me to go complicating a language definition in order
to protect programmers (who would need no protection had they any
taste) from one rather rare methodological gotcha out of myriad scads
of scads.  Of course, for any such alleged problem, one can concoct an
example of what could IN PRINCIPLE go wrong, but without some
plausible quantitative evidence of the seriousness of the problem, I
see no justification for attempting a rememdy.

I will illustrate by re-writing Mr. Hall's example just a bit (his
lines are preceded by >, my modifications of his lines by *>)

> Imagine:
>
>     Class A {
>  ...
>  A (char*);
>     }
>
*>      A f(const A& a, const A& b);
*>     // In the original: A operator+ (const A& a, const A& b);
>
*>  Now f("aa", "bb") has a meaning as an A.
>
> Six months later someone adds:
>
>     Class B {
>  ...
>  B (char*);
>     }
>
*>      B f(const B& a, const B& b);
*>     // In the original: B operator+ (const B& a, const B& b);
>
> Perhaps A is String and B is DecimalInt.
>
> Suddenly the expression becomes ambiguous and existing code fails.  It may
> not fail all at once of course.  Each module will only fail as it uses a B
> and includes B.h.  This should keep full employment amongst maintenance
> programmers.  Is that the objective :-)?
>
*> PS:  What is f("123","45")  Is it the String "12345"?  Or is it the
> DecimalInt "168"?

So, I presume we'll outlaw this, too?

Please understand; it is NOT a matter of my saying ``Oh yes, it is
ABSOLUTELY VITAL that I be able to define + so that "abc" + "def"
works.''  Rather, I am saying ``It (slightly) complexifies the C++
standard to outlaw the potential problems surrounding this example,
which seems rather rare.  Therefore, don't bother.''

P. Hilfinger

In article <2807oj$sks@agate.berkeley.edu>, hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
|>  [long quotes from ARM removed]
|> So, it appears that the ARM says, with no ambiguity at all, that
|> "aa" + "bb" is a perfectly legal expression.  Making this call illegal
|> would involve ADDING an additional restriction to the reference manual.

    The additional restriction is already present. Section 5.7 says that
pointer addition is not an allowed type combination.

    Jon
    __@/

In article <280a9lINNf56@borg.cs.unc.edu>, leech@cs.unc.edu (Jon Leech) writes:
> In article <2807oj$sks@agate.berkeley.edu>, hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
> |>  [long quotes from ARM removed]
> |> So, it appears that the ARM says, with no ambiguity at all, that
> |> "aa" + "bb" is a perfectly legal expression.  Making this call illegal
> |> would involve ADDING an additional restriction to the reference manual.
>
>     The additional restriction is already present. Section 5.7 says that
> pointer addition is not an allowed type combination.
>

Good try, but now the baby has been thrown out with the bathwater.  Section
5.7 says "The operands [of + and -] must be of arithmetic or pointer type."
In other words,

    class Complex {
        ...
        Complex operator+(const Complex&) const;  // ILLEGAL!
        ...
    };

May I suggest that this passage and the entire section had better
be a definition of the predefined operator+ functions only?

P. Hilfinger

In article <2807oj$sks@agate.berkeley.edu>, I wrote:

> ...  Personally, I've seen this
> kind of argument before during the Ada standardization, and it always
> seemed silly to me to go complicating a language definition in order
> to protect programmers (who would need no protection had they any
> taste) from one rather rare methodological gotcha out of myriad scads
> of scads.  Of course, for any such alleged problem, one can concoct an
> example of what could IN PRINCIPLE go wrong, but without some
> plausible quantitative evidence of the seriousness of the problem, I
> see no justification for attempting a rememdy.

In fairness to those currently working on Ada-9X, I should add that I
was referring here to my memories of the Ada-83 effort.  The Ada 9X
effort has been devoted to enhancements in functionality and has even
resulted in the removal of some of these purely methodological restrictions.

P. Hilfinger

In article <748860785snz@avondale.demon.co.uk>
jfhall@avondale.demon.co.uk (John Hall) writes:

|> In article <KANZE.93Sep23152253@slsvhdt.us-es.sel.de> kanze@us-es.sel.de writes:

|> > [deleted]

|> >Several people have cited this passage.  But in fact, in the code in
|> >question, the operator function is 'String operator+( const String& ,
|> >const String& ).'  Both of the arguments are of class type.

|> >The question is: can the compiler apply user defined conversions to
|> >match such a function, when none of the parameters to the addition are
|> >of user defined types?

|> >Although there is nothing in the ARM to support this, or even to
|> >suggest that it is true, many compilers refuse to do it.  In the
|> >standards committee, it is at present under warm discussion, and I
|> >would not like to wager on the outcome.

|> Imagine:

|>     Class A {
|>  ...
|>  A (char*);
|>     }

|>     A operator+ (const A& a, const A& b);

|> If we follow this suggestion then "aa" + "bb" acquires a meaning as an A.

|> Six months later someone adds:

|>     Class B {
|>  ...
|>  B (char*);
|>     }

|>     B operator+ (const B& a, const B& b);

|> Perhaps A is String and B is DecimalInt.

|> Suddenly the expression becomes ambiguous and existing code fails.  It may
|> not fail all at once of course.  Each module will only fail as it uses a B
|> and includes B.h.  This should keep full employment amongst maintenance
|> programmers.  Is that the objective :-)?

|> Surely this can never become valid.

|> PS:  What is "123"+"45"?  Is it the String "12345"?  Or is it the DecimalInt
|> "168"?

Just to make things clear...  I do not think that "123" + "45"
*should* be legal.  Only that there is nothing in the ARM that
currently forbids it (at least not explicitly).
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <283n1b$kjs@agate.berkeley.edu>
hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:

|> In article <280a9lINNf56@borg.cs.unc.edu>, leech@cs.unc.edu (Jon Leech) writes:
|> > In article <2807oj$sks@agate.berkeley.edu>, hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
|> > |>  [long quotes from ARM removed]
|> > |> So, it appears that the ARM says, with no ambiguity at all, that
|> > |> "aa" + "bb" is a perfectly legal expression.  Making this call illegal
|> > |> would involve ADDING an additional restriction to the reference manual.

|> >     The additional restriction is already present. Section 5.7 says that
|> > pointer addition is not an allowed type combination.

|> Good try, but now the baby has been thrown out with the bathwater.  Section
|> 5.7 says "The operands [of + and -] must be of arithmetic or pointer type."
|> In other words,

|>     class Complex {
|>         ...
|>         Complex operator+(const Complex&) const;  // ILLEGAL!
|>         ...
|>     };

|> May I suggest that this passage and the entire section had better
|> be a definition of the predefined operator+ functions only?

This *is* the case.  The entire section only applies to built-in
types.  But pointers are built-in types, ie: the section applies to
pointers.

I don't really pretend to know if the above is a valid argument, but
some committee members have presented it.  I think quite frankly that
the standard will have to be somewhat clearer than the ARM is here.
(I think it will be; this point has already been brought up in the
standards committee, and it will no doubt be resolved explicitly one
way or another.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung