In article <190@davgar>, david@davgar.arlington.va.us (David Garfield) writes:
|> >>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")

Sorry.  Section 5.4 of the reference manual:

 A pointer may be *explicitly* converted to any integral type large
 enough to hold it. [emphasis mine]

Your conversions above are *implicit* conversions.  There is no implicit
conversion from a pointer to an integral type, therefore, only your third
version ( A("a") + A("b") ) could be a valid match.
--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
                       (Send mail to either address)
-------------------------------------------------------------------------

> In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
> >The ARM is generally interpreted as forbidding user defined operators
> >when all of the types are built in.

To which comes the R. F. Guilmette's response

In article <rfgCDIxGH.GrE@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
> Nonsense.  There is no basis for such an interpretation.

... except of course this sentence in r.13.4 in the C++ Programming
Language, 2nd ed.,

   ``An operator function must either be a member function or take at
     least one argument of a class or a reference to a class.''

which might understandably be interpreted as Mr. Kanze suggests.

The rationale provided for this in the ARM (pg. 330) is

   ``The intent is to make C++ extensible, but not mutable.  This
     protects the C++ programmer from the most obvious abuses of operator
     overloading, such as redefining `+' on integers to mean
     subtraction.''

Personally, I find this particular rationale rather shaky.  Protect
from WHOSE abuse,  exactly?  The bad programmer's, I suppose.  The
sources of bad (i.e., obfuscated) programming, however, are so vast
that it seems utterly pointless to swat this one little gnat,
especially when there seem to be uses for the some of the more
beneficial insects that got swatted with it.  So, does anyone have a
better rationale for the cited restriction?  Is it being modified in
standardization?

P. Hilfinger

In article <27gvn5$5fl@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>
>> In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>> >The ARM is generally interpreted as forbidding user defined operators
>> >when all of the types are built in.
>
>To which comes the R. F. Guilmette's response
>
>In article <rfgCDIxGH.GrE@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>> Nonsense.  There is no basis for such an interpretation.
>
>... except of course this sentence in r.13.4 in the C++ Programming
>Language, 2nd ed.,
>
>   ``An operator function must either be a member function or take at
>     least one argument of a class or a reference to a class.''
>
>which might understandably be interpreted as Mr. Kanze suggests.

I hardly think so!

When the ARM talks about a function "taking" a given type of actual argu-
ment what it is really trying to say is that the function has a formal
parameter declared to be of the given type *and* it is called with some
expression which either *is* or which may be *converted to* the given type.

Here is an example which ought to help clarify this:

 char *cp;
 struct S { S(char*) { } } S_object(cp);

 S function (const S&, const S&) { return S_object; }
 S operator+(const S&, const S&) { return S_object; }

 void
 test ()
 {
   S v1 = function("abc" , "xyz");  // ok!
   S v2 =          "abc" + "xyz";   // likewise ok, for the same reasons!
 }

The example above contains four string literals.  It should be apparent
(I hope) that all four of them should be implicitly converted to type `S'
values.  (I do not see how a convincing case can be made for any other
possibility.)

I would further claim that it is equally obvious that all "conformant"
compilers should accept *all* of the source lines of the above example
without complaint.

(Implementors in the audience may wish to try this on their respective
implementations and verify that this example is correctly handled.)

--

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