In article <KABXcfA0UzN3Ew98@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:

> In article <slrn7jdpol.nmg.sbnaran@localhost.localdomain>, Siemel Naran
> <sbnaran@localhost.localdomain.COM> writes
> >
> >On 10 May 99 12:02:40 GMT, G.B. <me@web1.ucar.edu> wrote:
> >
> >>> >In essence, I recently tried overloading function fn():
> >>> >  void fn(int n);
> >>> >  void fn(int &n);
> >>> >
> >>> >making a call:
> >>> >  int i = 5;
> >>> >  fn(i);
> >>> >
> >>> >the first version of fn( ) was invoked (on two different compilers);
> >>> >what I do not understand is:
> >>> >  although the signatures of the two functions is different, how can the
> >>> >compiler distinguish from the call which fn( ) to invoke?
> >
> >>I believe both of that compilers are wrong. There is an ambiguity in calling
> >>fn(i), so compiler must give an error message.
> >
> >Are you sure of this?  Two excellent compilers (como and egcs) invoke
> >fn(int).
>
> Yes, I'm sure and that just shows that even excellent compilers are
> still far from perfect.  There has always been an ambiguity error for
> such prototypes (for as long as I can remember)

In CD2, paragraph 3 of section 13.3.3.2 read:

  Two implicit conversion sequences of the same form are indistinguishable
  conversion sequences unless one of the following rules apply:

      Standard conversion sequence S1 is a better conversion sequence than
      standard conversion sequence S2 if

        S1 is a proper subsequence of S2 (comparing the conversion sequences
        in the canonical form defined by 13.3.3.1.1; the identity conversion
        sequence is considered to be a subsequence of any non-identity
        conversion sequence) or, if not that,

As of the July 1997 draft this paragraph read:

  Two implicit conversion sequences of the same form are indistinguishable
  conversion sequences unless one of the following rules apply:

      Standard conversion sequence S1 is a better conversion sequence than
      standard conversion sequence S2 if

        S1 is a proper subsequence of S2 (comparing the conversion sequences
        in the canonical form defined by 13.3.3.1.1,
        >>>>>>>>>>  excluding any Lvalue Transformation;  <<<<<<<<<<
                                                     the identity conversion
        sequence is considered to be a subsequence of any non-identity
        conversion sequence) or, if not that,

The "Lvalue Transformation" is the lvalue-to-rvalue conversion described in
section 4.1.  This conversion is required for the call "fn(i)" to "fn(int)"
above since "i" is an lvalue and "fn(int)" takes an rvalue argument.

This change was prompted by the paper "The weight of the lvalue-to-rvalue
conversion in overload resolution", N1084/97-0046, 2-June-1997.  This paper
pointed out that taking the lvalue-to-rvalue conversion into account could
cause some surprising results in overload resolution.  The paper discusses
section 13.4.2 of the ARM, page 333:

        struct X {
            X operator+(int);
        };

        X operator+(X,double);

        void g(X b) {
            X a;
            a = b+1.0; // ARM says ::operator+(X,double)
        }

        The implicit conversion sequences are as follows:

          X::operator+         X lvalue --> X& (identity)
                               double --> int (conversion)

          ::operator+          X lvalue --> X (lvalue-to-rvalue)
                               double --> double (identity)

        So the first argument is better for the member function, but the
    second argument is better for the non-member function, and the call
    is ambiguous.

There are also issues with partial ordering of function templates.
It might be possible to design overloading rules which solve these problems
without ignoring the lvalue-to-rvalue conversion, but the problems were
discovered after CD2 and it was rather late to begin significant changes
to the overload resolution rules.  Removing the lvalue-to-rvalue conversion
from the overloading rules appeared to be the best solution at the time.

Since there were production compilers which implemented the CD2 semantics,
it is only reasonable that some vendors would continue to support those
semantics so as to continue to accept code written prior to July 1997.
However those compilers might not handle the "operator+" example above.

Any vendor which solves the "operator+" problem while still allowing the
original example "fn(i)" to work could consider submitting their
solution as a proposal for a future change to the standard - especially
if other vendors make similar changes for compatibility.


-- Bill Gibbons
   bill@gibbons.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37384E96.75A@wanadoo.fr>, Valentin Bonnard
<Bonnard.V@wanadoo.fr> writes
>ctually, no, it hasn't always been an ambiguity. It accidentally
>became non ambiguous, in favor of f(int&) (I don't know when), then
>was changed back to ambiguous (London 97).

Well I rarely notice accidents unless they happen to me:)
>
>(I conclude that your memory is limited to two years.)

I think that is a false conclusion, but maybe I am getting old :)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hhqok$jlh$1@nnrp1.deja.com>, gbush@my-dejanews.com writes
>If popularity is the primary concern of a language developer than
>his/her place is in a marketing department. And one more thought: those
>who rely on popularity may find themselves very unpopular one day; and
>those who seek the right solution despite popularity may happen to
>become very popular.
>Gene.

Sorry but commercial experience does not support this idealistic view.
Internal Combustion engines are an example.  There are many potentially
better alternatives but they cannot compete with a highly developed
system supported by entrenched interests.  We each have a considerable
investment in our acquired skills and suggesting that we throw them away
just does not work.

If you ignore the marketplace it will ignore you.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 15 May 1999 15:56:36 GMT, Greg Comeau <comeau@panix.com> wrote:

>como (Comeau C++) gives an error, assuming the exact 4 lines of code above.
>Did you use a const in an example or something?

Indeed, you are right.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hhqok$jlh$1@nnrp1.deja.com>,
  Honorable Gbush <gbush@my-dejanews.com> wrote:
> Ah, if popularity is the primary concern of a language developer
> than his/her place is in a marketing department.

I say, Honorable Gbush very verrrry smart, oh! However, this
honorable student want to see other side of coin:

  If popularity is not at all a concern for a language developer,
  then his/her place is in tiny lab very verrry sealed, so that
  nobody can be harmed, oh oh!

This humble student thanks you. Oh!

----
Allan_W@my-dejanews.com is a "Spam Magnet" --
never read.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7jdpol.nmg.sbnaran@localhost.localdomain>,
sbnaran@localhost.localdomain.COM says...

[ choosing be fn(int) and fn(int &) in `int I; fn(i);' ]

> >I believe both of that compilers are wrong. There is an ambiguity in calling
> >fn(i), so compiler must give an error message.
>
> Are you sure of this?  Two excellent compilers (como and egcs) invoke
> fn(int).  And I even changed the order of the declarations.  Although
> I agree with you that an error or warning should be in order.

I'm not _sure_, but I believe there is a real ambiguity and the
compilers are in error.  According 13.3.3.1.4/1 (reference binding):

 When a parameter of reference type binds directly (8.5.3)
 to an argument expression, the implicit conversion sequence
 is the identity conversion...

According to 8.5.3, a "reference type binds directly" to an expression
if it:
 is an lvalue (but is not a bit-field) and "cv1 T1" is
 reference-compatible with "cv2 T2"

In the example given `i' is an lvalue and `int' is reference
compatible with `int &', so there is an identity conversion (I.e. no
conversion at all) in passing `i' as either an int or a reference to
an int.  By my reading, that means neither should be preferred over
the other and the call is ambiguous.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7jdpol.nmg.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain.COM> writes
>
>On 10 May 99 12:02:40 GMT, G.B. <me@web1.ucar.edu> wrote:
>
>>> >In essence, I recently tried overloading function fn():
>>> >  void fn(int n);
>>> >  void fn(int &n);
>>> >
>>> >making a call:
>>> >  int i = 5;
>>> >  fn(i);
>>> >
>>> >the first version of fn( ) was invoked (on two different compilers);
>>> >what I do not understand is:
>>> >  although the signatures of the two functions is different, how can the
>>> >compiler distinguish from the call which fn( ) to invoke?
>
>>I believe both of that compilers are wrong. There is an ambiguity in calling
>>fn(i), so compiler must give an error message.
>
>Are you sure of this?  Two excellent compilers (como and egcs) invoke
>fn(int).

Yes, I'm sure and that just shows that even excellent compilers are
still far from perfect.  There has always been an ambiguity error for
such prototypes (for as long as I can remember)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <slrn7jdpol.nmg.sbnaran@localhost.localdomain>, Siemel Naran
> <sbnaran@localhost.localdomain.COM> writes
> >
> >On 10 May 99 12:02:40 GMT, G.B. <me@web1.ucar.edu> wrote:
> >
> >>> >In essence, I recently tried overloading function fn():
> >>> >  void fn(int n);
> >>> >  void fn(int &n);
> >>> >
> >>> >making a call:
> >>> >  int i = 5;
> >>> >  fn(i);

> There has always been an ambiguity error for
> such prototypes (for as long as I can remember)

Actually, no, it hasn't always been an ambiguity. It accidentally
became non ambiguous, in favor of f(int&) (I don't know when), then
was changed back to ambiguous (London 97).

(I conclude that your memory is limited to two years.)

But I don't think it has ever been f(int).

--

Valentin Bonnard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"G.B." <me@web1.ucar.edu> writes:

>I often think, had C++ be based on Pascal
>instead of C it would be a cleaner language.

Indeed it would. It would be at least as nice as Modula,
and it might have become as popular as Modula. :-)

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7hfba5$nhd$1@engnews1.eng.sun.com>,
  stephen.clamage@sun.com (Steve Clamage) wrote:
>
> "G.B." <me@web1.ucar.edu> writes:
>
> >I often think, had C++ be based on Pascal
> >instead of C it would be a cleaner language.
>
> Indeed it would. It would be at least as nice as Modula,
> and it might have become as popular as Modula. :-)
>
If popularity is the primary concern of a language developer than
his/her place is in a marketing department. And one more thought: those
who rely on popularity may find themselves very unpopular one day; and
those who seek the right solution despite popularity may happen to
become very popular.
Gene.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

G.B. <me@web1.ucar.edu> writes:
>> I often think, had C++ be based on Pascal
>> instead of C it would be a cleaner language.

Steve Clamage wrote:
> Indeed it would. It would be at least as nice as Modula,
> and it might have become as popular as Modula. :-)

On the other hand, Modula-2 and Oberon undoubtedly would have
replaced Pascal completely if they had been called Pascal-2 and
Pascal-3 instead.

Or Pascal++.

I believe that C++ is as popular as it is now because it is called
C++, having gained mindshare with existing C users at the time, and
winning out over Objective-C.  (It could also be argued that it was
popular because it came out of Bell Labs, but this is a weaker
argument - witness the limited appeal of Plan 9.)  C++ also had
the advantage that it could leverage off of existing C code and
programming talent.

But C++ could be made "cleaner", by applying a few changes like:

 1. Get rid of typecasts (especially between pointers and integers).

 2. Make arrays first-class objects.

 3. Make 'char' a real character type instead of a numeric type.

 4. Replace '#include' with 'import' and let the compiler deal with
  the details of exportable declarations instead of requiring header
  files.

 5. Add a 'null' keyword.

But no one is seriously suggesting that we do any of these.
(Can you say "Java"?)

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7jdpol.nmg.sbnaran@localhost.localdomain> sbnaran@uiuc.edu writes:
>
>On 10 May 99 12:02:40 GMT, G.B. <me@web1.ucar.edu> wrote:
>
>>> >In essence, I recently tried overloading function fn():
>>> >  void fn(int n);
>>> >  void fn(int &n);
>>> >
>>> >making a call:
>>> >  int i = 5;
>>> >  fn(i);
>>> >
>>> >the first version of fn( ) was invoked (on two different compilers);
>>> >what I do not understand is:
>>> >  although the signatures of the two functions is different, how can the
>>> >compiler distinguish from the call which fn( ) to invoke?
>
>>I believe both of that compilers are wrong. There is an ambiguity in calling
>>fn(i), so compiler must give an error message.
>
>Are you sure of this?  Two excellent compilers (como and egcs) invoke
>fn(int).  And I even changed the order of the declarations.  Although
>I agree with you that an error or warning should be in order.

como (Comeau C++) gives an error, assuming the exact 4 lines of code above.
Did you use a const in an example or something?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:

: On the other hand, Modula-2 and Oberon undoubtedly would have
: replaced Pascal completely if they had been called Pascal-2 and
: Pascal-3 instead.

: Or Pascal++.

Nope, only us academics would have jumped on that.  I rejected them
as an attempt to make an academic language usable in industry.  OTOH,
using an industrial language in academia seemed reasonable.

: I believe that C++ is as popular as it is now because it is called
: C++, having gained mindshare with existing C users at the time, and
: winning out over Objective-C.

Likely true other than the name.

: C++ also had
: the advantage that it could leverage off of existing C code and
: programming talent.

That's what you almost said above.  Yes, of course.  See D&E.

: But C++ could be made "cleaner", by applying a few changes like:

:  1. Get rid of typecasts (especially between pointers and integers).

Ah, for the good old days when men were men, women were women, and
pointers were ints!  Yes, get rid of the casts and just let me do an
assignment. :)

:  2. Make arrays first-class objects.

Why?  Vectors are.

:  3. Make 'char' a real character type instead of a numeric type.

Why? I like short short int.  It's as useful as long long int.

:  5. Add a 'null' keyword.

I've read your posts and will not reopen this one :)

: But no one is seriously suggesting that we do any of these.
: (Can you say "Java"?)

Yes.  It's an island and a nickname for the stuff I drink most of the
day.  Did you have something else in mind?

Did I byte on a troll?

John



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> >
> >In essence, I recently tried overloading function fn():
> >  void fn(int n);
> >  void fn(int &n);
> >
> >making a call:
> >  int i = 5;
> >  fn(i);
> >
> >the first version of fn( ) was invoked (on two different compilers);
> >what I do not understand is:
> >  although the signatures of the two functions is different, how can the
> >compiler distinguish from the call which fn( ) to invoke?

I believe both of that compilers are wrong. There is an ambiguity in calling
fn(i), so compiler must give an error message.
It seems to me that C++ is muddy when it comes to the function parameter
types. For example, void fn(int& n) should have meant the function that
accepts parameters of type int&. But instead it means what Pascal signifies
by "var" parameter. It would be much better if C++ used the same kind of
sintax: void fn( var int) that would be different from void fn(int&). Were
it done this way, there wouldn't be ambiguity in your example, because "i"
is declared to be int, not int&. I often think, had C++ be based on Pascal
instead of C it would be a cleaner language.
Gene.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 May 99 12:02:40 GMT, G.B. <me@web1.ucar.edu> wrote:

>> >In essence, I recently tried overloading function fn():
>> >  void fn(int n);
>> >  void fn(int &n);
>> >
>> >making a call:
>> >  int i = 5;
>> >  fn(i);
>> >
>> >the first version of fn( ) was invoked (on two different compilers);
>> >what I do not understand is:
>> >  although the signatures of the two functions is different, how can the
>> >compiler distinguish from the call which fn( ) to invoke?

>I believe both of that compilers are wrong. There is an ambiguity in calling
>fn(i), so compiler must give an error message.

Are you sure of this?  Two excellent compilers (como and egcs) invoke
fn(int).  And I even changed the order of the declarations.  Although
I agree with you that an error or warning should be in order.

The situation is similar to calling a function with a template
parameter: the compiler prefers passing by value.
   template <class T> void f(T);
   void g(const Thing& t) { f(t); }
      // does it call  void f<const Thing&>(const Thing&)
      // or  void f<Thing>(Thing)
Turns out that it calls f<Thing>(Thing).

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jerry44@my-dejanews.com wrote in message
<7goqkb$ro7$1@nnrp1.dejanews.com>...
>I suspect I don't understand something basic about function overloading,
>but ...
>
>In essence, I recently tried overloading function fn():
>  void fn(int n);
>  void fn(int &n);
>
>making a call:
>  int i = 5;
>  fn(i);
>
>the first version of fn( ) was invoked (on two different compilers);
>what I do not understand is:
>  although the signatures of the two functions is different, how can the
>compiler distinguish from the call which fn( ) to invoke?
>
>why did it invoke the pass by value form? (switching the declaration
>order had no effect)
>
>why did it compile and run?
>


I think you will get better answers at comp.std.c++. I took the liberty to
include that group.

HTH,
Martijn
--
My reply-to address is intentionally set to /dev/null
reply to <newsgroupname> at greebo.orion in nl




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]