In article <KANZE.93Sep20132927@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <rfgCDIxGH.GrE@netcom.com> rfg@netcom.com (Ronald F.
>Guilmette) writes:
>
>|> In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>|> >In article <27a8hf$711@charm.magnus.acs.ohio-state.edu>
>|> >liren@magnus.acs.ohio-state.edu (Liming Ren) writes:
>
>|> >|> In Lippman's book, he defines a class String:
>
>|> >|> class String{
>|> >|>  private:
>|> >|>    int len;
>|> >|>    char *str;
>
>|> >|>  ...
>|> >|> }
>
>|> >|> and then defines a non member operator + as
>|> >|> operator+(const String&, const String&);
>
>|> >|> This operator + works on:
>
>|> >|>  "cobble"+String,   String+"cobble".
>|> >|> But not on:  "cobble"+"stone".  I can't figure out why. It is
>|> >|> exercise 6.11 on page 308.
>
>|> >Because the language forbids it (maybe).
>
>|> >The ARM is generally interpreted as forbidding user defined operators
>|> >when all of the types are built in.
>
>|> Nonsense.  There is no basis for such an interpretation.
>
>Strictly speaking, I think Ron is right.  At least, I am unable to
>find language in the ARM which supports this interpretation.  The fact
>that there is no basis for such an interpretation, however, has not
>stopped most compiler writers from adapting it.

Yes.  Most implementors have endeavored to be fully cfront-compatible...
right down to the bugs.  (I'm not sure that I blame them.)

--

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

In article <27a8hf$711@charm.magnus.acs.ohio-state.edu> liren@magnus.acs.ohio-state.edu (Liming Ren) writes:
>
>In Lippman's book, he defines a class String:
>
>class String{
> private:
>   int len;
>   char *str;
>
> ...
>}
>
>and then defines a non member operator + as
>operator+(const String&, const String&);
>
>This operator + works on:
>
> "cobble"+String,   String+"cobble".
>But not on:  "cobble"+"stone".  I can't figure out why. It is
>exercise 6.11 on page 308.
>
>Please help!!
>

As it happens, this very question has been discussed recently within the
C++ standardization committee.

The committee has yet to make up its collective mind whether or not both
operands of a user-defined (non-member) operator may be type-converted
(implicitly) via user-defined type conversions.

In the meantime, use of explicit casts should be sufficient to render all
such cases totally unambiguous.

Follow-ups to comp.std.c++ please.

--

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

In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <27a8hf$711@charm.magnus.acs.ohio-state.edu>
>liren@magnus.acs.ohio-state.edu (Liming Ren) writes:
>
>|> In Lippman's book, he defines a class String:
>
>|> class String{
>|>  private:
>|>    int len;
>|>    char *str;
>
>|>  ...
>|> }
>
>|> and then defines a non member operator + as
>|> operator+(const String&, const String&);
>
>|> This operator + works on:
>
>|>  "cobble"+String,   String+"cobble".
>|> But not on:  "cobble"+"stone".  I can't figure out why. It is
>|> exercise 6.11 on page 308.
>
>Because the language forbids it (maybe).
>
>The ARM is generally interpreted as forbidding user defined operators
>when all of the types are built in.

Nonsense.  There is no basis for such an interpretation.

--

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

In article <rfgCDIxGH.GrE@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>>
>>|> This operator + works on:
>>
>>|>  "cobble"+String,   String+"cobble".
>>|> But not on:  "cobble"+"stone".  I can't figure out why. It is
>>|> exercise 6.11 on page 308.
>>
>>Because the language forbids it (maybe).
>>
>>The ARM is generally interpreted as forbidding user defined operators
>>when all of the types are built in.
>
>Nonsense.  There is no basis for such an interpretation.
>

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

The obvious meaning of this statement is that it forbids user defined operators
when all of the types are built in, so I think it's quite clear that there
is a basis for this interpretation. There may well be other sections that
conflict with this (although I don't see any mention of them in the prior
posting), but that certainly does not mean that there is _no basis_ for
this interpretation.
 -- Pete

In article <rfgCDIxGH.GrE@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> >In article <27a8hf$711@charm.magnus.acs.ohio-state.edu>
|> >liren@magnus.acs.ohio-state.edu (Liming Ren) writes:

|> >|> In Lippman's book, he defines a class String:

|> >|> class String{
|> >|>  private:
|> >|>    int len;
|> >|>    char *str;

|> >|>  ...
|> >|> }

|> >|> and then defines a non member operator + as
|> >|> operator+(const String&, const String&);

|> >|> This operator + works on:

|> >|>  "cobble"+String,   String+"cobble".
|> >|> But not on:  "cobble"+"stone".  I can't figure out why. It is
|> >|> exercise 6.11 on page 308.

|> >Because the language forbids it (maybe).

|> >The ARM is generally interpreted as forbidding user defined operators
|> >when all of the types are built in.

|> Nonsense.  There is no basis for such an interpretation.

Strictly speaking, I think Ron is right.  At least, I am unable to
find language in the ARM which supports this interpretation.  The fact
that there is no basis for such an interpretation, however, has not
stopped most compiler writers from adapting it.
--
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 <rfgCDIxGH.GrE@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
<In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
<>In article <27a8hf$711@charm.magnus.acs.ohio-state.edu>
<>liren@magnus.acs.ohio-state.edu (Liming Ren) writes:
<>
<>|> In Lippman's book, he defines a class String:
<>
<>|> class String{
<>|>  private:
<>|>    int len;
<>|>    char *str;
<>
<>|>  ...
<>|> }
<>
<>|> and then defines a non member operator + as
<>|> operator+(const String&, const String&);
<>
<>|> This operator + works on:
<>
<>|>  "cobble"+String,   String+"cobble".
<>|> But not on:  "cobble"+"stone".  I can't figure out why. It is
<>|> exercise 6.11 on page 308.
<>
<>Because the language forbids it (maybe).
<>
<>The ARM is generally interpreted as forbidding user defined operators
<>when all of the types are built in.
<
<Nonsense.  There is no basis for such an interpretation.

Doesn't the reference manual, section 13.4, say: "An operator function must
either be a member function or take at least one argument of a class or
a reference to a class" ?
--
 Jan Bielawski
 Computervision, San Diego
 jpb@cvsd.prime.com

In article <6065@calmasd.Prime.COM> jpb@calmasd.prime.com (Jan
Bielawski) writes:

|> In article <rfgCDIxGH.GrE@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|> <In article <KANZE.93Sep17132928@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> <>In article <27a8hf$711@charm.magnus.acs.ohio-state.edu>
|> <>liren@magnus.acs.ohio-state.edu (Liming Ren) writes:
|> <>
|> <>|> In Lippman's book, he defines a class String:
|> <>
|> <>|> class String{
|> <>|>  private:
|> <>|>    int len;
|> <>|>    char *str;
|> <>
|> <>|>  ...
|> <>|> }
|> <>
|> <>|> and then defines a non member operator + as
|> <>|> operator+(const String&, const String&);
|> <>
|> <>|> This operator + works on:
|> <>
|> <>|>  "cobble"+String,   String+"cobble".
|> <>|> But not on:  "cobble"+"stone".  I can't figure out why. It is
|> <>|> exercise 6.11 on page 308.
|> <>
|> <>Because the language forbids it (maybe).
|> <>
|> <>The ARM is generally interpreted as forbidding user defined operators
|> <>when all of the types are built in.
|> <
|> <Nonsense.  There is no basis for such an interpretation.

|> Doesn't the reference manual, section 13.4, say: "An operator function must
|> either be a member function or take at least one argument of a class or
|> a reference to a class" ?

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.

I still think that the careful user will provide an explicite cast if
that is what he wants, ie: (String)"cobble" + (String)"stone".
--
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