Topic: overloading resolution and const


Author: sdm@cs.brown.edu (Scott Meyers)
Date: 31 Jan 91 17:42:39 GMT
Raw View
In the ARM description of conversion sequences for matching actual
parameters to formals during resolution of calls to overloaded functions,
it says the first thing tried is:

    [1] Exact match:  Sequences of zero or more trivial conversions are
        better than all other sequences.  Of these, those that do not
        convert T* to const T*, T* to volatile T*, T& to const T&, or T& to
        volatile T& are better than those that do. (ARM, p. 318.)

How does the fact that not converting to const or volatile is "better"
enter into things?  That is, under what conditions would this part of rule
[1] determine which function should be called?

The single-parameter case doesn't seem to lend any insight, since no
compiler I have access to will accept the following two functions in the
same scope:

    void f(double) {}
    void f(const double) {}

I tried concocting a two-parameter example that would lend some insight,
but I was unable to do so (especially after I got different behavior from
g++, cfront 2.0, and cfront 2.1 on one example).  Can anyone help clarify
the purpose of the above statement that lack of conversion to
const/volatile within an exact match is better?

Thanks,

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."




Author: sarima@tdatirv.UUCP (Stanley Friesen)
Date: 1 Feb 91 16:12:17 GMT
Raw View
In article <63156@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
>The single-parameter case doesn't seem to lend any insight, since no
>compiler I have access to will accept the following two functions in the
>same scope:
>
>    void f(double) {}
>    void f(const double) {}

Certainly not, these two are equivalent, since argument passing is by value,
not by reference (unless specificly declared otherwise).  You might have
noticed that the text you cited from the ARM only mentions pointer and
reference types in the context of the 'const' qualifier.  Thus you might
try the following pair:

    void f(double &);
    void f(const double &);

A cfront 2.X compatible compiler had better accept both of these in the
same scope, or it is not truly 2.X compatible.

Now with these declared the following code will call each one in turn:

    double nd;
    const double cd;
    f(nd);  /* calls f(double&) since this avoids a 'const' */
    f(cd);  /* cals f(const double&) since const required   */


I hope this clarifies the matter.
--
---------------
uunet!tdatirv!sarima    (Stanley Friesen)




Author: mat@mole-end.UUCP (Mark A Terribile)
Date: 3 Feb 91 07:42:33 GMT
Raw View
In article <63156@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes:
> In the ARM description of conversion sequences for matching actual
> parameters to formals during resolution of calls to overloaded functions,
> it says the first thing tried is:

>     [1] Exact match:  Sequences of zero or more trivial conversions are
>         better than all other sequences.  Of these, those that do not
>         convert T* to const T*, T* to volatile T*, T& to const T&, or T& to
>         volatile T& are better than those that do. (ARM, p. 318.)

> How does the fact that not converting to const or volatile is "better"
> enter into things?  That is, under what conditions would this part of rule
> [1] determine which function should be called?

> The single-parameter case doesn't seem to lend any insight, since no
> compiler I have access to will accept the following two functions in the
> same scope:

>     void f(double) {}
>     void f(const double) {}

Actually, it provides all the insight in the world!  The first will be
called with an argument of type  double , and the second with arguments of
type  const double .

These are probably not the most useful cases.  If, on the other hand,
you had

 void f( Something& );
 void f( const Something& );

the first would be called when the  Something  could be altered, and the
second when it could not.

--

 (This man's opinions are his own.)
 From mole-end    Mark Terribile