Andrea Ferro <AndreaF@UrkaDVD.it> wrote in message
news:9cej07$jb2$1@serv1.iunet.it...
> "scott douglass" <sdouglass@arm.com> wrote in message
> news:4.3.2.7.2.20010427163120.02575d78@mail1...
> > Hello,
> >
> > This is closely related to core issue #260
> > <http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#260> but is
not
> > resolved by the suggested resolution there.
>
> Personally I'm not sure that issue is right. If the interpretation there
is
> correct then
>
> short s1,s2;
> s1=s2;
>
> should also try to use "short& operator=(short&, int);" and I think this
is not
> the case. I think the "R is a promoted arithmetic type" wording is either
> misleading (if it means that the type is promoted tu cv unqualified
version of
> L) or in conflict with 5.17 sub 3.
>
> The issue says:
>
> struct T {
>     operator short() const;
>     operator int() const;
> };
>
> short s;
>
> void f(const T& t) {
>     s = t;  // surprisingly calls T::operator int() const
> }
>
> I do not agree. It should not call "T::operator int() const" but
"T::operator
> short() const" for the standard as is.
Wrong, for the current version of the standard 'T::operator int() const'
shall be called. 's = t' is not a declaration-statement, it's an
expression-statement. See my previous posting to this thread.

> > Given:
> >
> > struct T {
> >      operator int() const;
> >      operator double() const;
> > };
> >
> > I believe the standard requires the following assignment to be ambiguous
> > (even though I expect that would surprise the user):
>
> I believe not. I think it should work as expected.
The assignment is indeed ill-formed.

> > double x;
> > void f(const T& t) { x = t; }
> >
> > The problem is that both of these built-in operator=()s exist (13.6/18
> > [over.built]):
> >          double& operator=(double&, int);
> >          double& operator=(double&, double);
>
> I think the first one does not exist.
It does exist as well as lot of others like:
volatile double& operator=(volatile double&, int); or
volatile double& operator=(volatile double&, long double); etc..

>
> > Can you find a rule in the standard that makes one a better match than
the
> > other?
>
> 5.17 sub 3. Not a better match, a different interpretation of the
promotion that
> the second operand should undergo.
What is described there applies to what the selected built-in candidate will
do, once the overload resolution has succeeded. In no way does 5.17/3 impose
any restrictions on the overload resolution process. See 13.3.1.2/3-4 and
13.6 for that matter.


Cheers,

Andrei Iltchenko.



---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"scott douglass" <sdouglass@arm.com> wrote in message
news:4.3.2.7.2.20010427163120.02575d78@mail1...
> Hello,
>
> This is closely related to core issue #260
> <http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#260> but is not
> resolved by the suggested resolution there.

Personally I'm not sure that issue is right. If the interpretation there is
correct then

short s1,s2;
s1=s2;

should also try to use "short& operator=(short&, int);" and I think this is not
the case. I think the "R is a promoted arithmetic type" wording is either
misleading (if it means that the type is promoted tu cv unqualified version of
L) or in conflict with 5.17 sub 3.

The issue says:

struct T {
    operator short() const;
    operator int() const;
};

short s;

void f(const T& t) {
    s = t;  // surprisingly calls T::operator int() const
}

I do not agree. It should not call "T::operator int() const" but "T::operator
short() const" for the standard as is.

> Given:
>
> struct T {
>      operator int() const;
>      operator double() const;
> };
>
> I believe the standard requires the following assignment to be ambiguous
> (even though I expect that would surprise the user):

I believe not. I think it should work as expected.

> double x;
> void f(const T& t) { x = t; }
>
> The problem is that both of these built-in operator=()s exist (13.6/18
> [over.built]):
>          double& operator=(double&, int);
>          double& operator=(double&, double);

I think the first one does not exist.

> Can you find a rule in the standard that makes one a better match than the
> other?

5.17 sub 3. Not a better match, a different interpretation of the promotion that
the second operand should undergo.

--

Andrea Ferro

---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556



---
[ 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://www.research.att.com/~austern/csc/faq.html                ]