<8gisjm$sfv$1@sun27.hrz.tu-darmstadt.de> <392FE879.FDAEAEEE@mx1.ttcn.ne.jp>
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]

Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
) Matthias Meixner wrote:
) >
) > Just to make sure I have got it. The following should be ambiguous, right?
) >
) > struct A {int a;};
) > struct B: public A { B() {}; int b;};
) >
) > struct X {
) >    B x;
) >    operator A &() { return x; }
) >    operator B &() { return x; }
) > };
) >
) > main()
) > {
) >    X x;
) >    A &g=x; // ambigous
) > }
)
) Yes, I agree.
) I think this is ambiguous.

Overall it looks like its time to write a defect report, since the handling
of references regarding user defined conversions is quite inconsistent:

- the overloading is inconsistent compared to the handling of pointers.
- the overloading used to select conversion functions is inconsistent
  with the overloading used to select 'normal' functions.

Overall it looks like the actual standard does not reflect the intention
of the authors, since for the other cases of overloading, there are
special sections for the handling of references (e.g. in 13.3.3.2).

Maybe I will write a defect report myself, or is there already one, that
covers this problem?

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701



---
[ 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              ]

Matthias Meixner wrote:
>
> Just to make sure I have got it. The following should be ambiguous, right?
>
> struct A {int a;};
> struct B: public A { B() {}; int b;};
>
> struct X {
>    B x;
>    operator A &() { return x; }
>    operator B &() { return x; }
> };
>
> main()
> {
>    X x;
>    A &g=x; // ambigous
> }

Yes, I agree.
I think this is ambiguous.


Hideaki Onaru

---
[ 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              ]

Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:

[...]

) And, Z& -> const Z& is NOT a qualification adjustment.
) 4.4 (Qualification conversion) refers to POINTERS only.
) Z& -> const Z& is just a binding. (Read 8.5.3/5 again.)

OK, this combinations seems to make the problems.

Just to make sure I have got it. The following should be ambiguous, right?

struct A {int a;};
struct B: public A { B() {}; int b;};

struct X {
   B x;
   operator A &() { return x; }
   operator B &() { return x; }
};

main()
{
   X x;
   A &g=x; // ambigous
}

Both conversion functions are candidate functions, since the result of
both can be bound to references to A. None of them is better than the other
one, since 13.3.3.2 cannot be used to compare the result of the conversion functions
since there is no conversion but only a direct binding (you could call that identity
conversion, but that is confusing).

Somehow I have got the impression that the standard is quite badly broken
with respect to conversion functions that return references, since it introduces
unnecessery inconsistencies in the handling of references vs. pointers.

BTW. gcc happily accepts the above code.

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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              ]

Matthias Meixner wrote:
>
> Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
> ) I don't understand how you can say that const Z& -> const Z& is a proper
> ) subsequence of Z& -> const Z& (13.3.3.2/3 says that identity conversion
> ) sequence is considered to be a subsequence of any NON-IDENTITY conversion
> ) sequence, but in this case, both sequences are identity conversion sequences).
>
> The question is: does 13.3.3.1.4 apply in this case?
> If no:  Z& -> const Z& is a qualification adjustment, i.e. no identity conversion
> If yes: Z& -> const Z& is an identity conversion.

NO.
Because Z& is the type of the RESULT of conversion by conversion function.
As I've written several times, implicit conversion is a conversion from
argument to the parameter of the function under consideration (in our case, B&
to const B&, etc).
You are still confusing conversion BEFORE conversion function and "conversion"
AFTER conversion function.
In other words, you mix up the WHOLE conversion B& to const Z& (etc) with
conversion to the parameter of the conversion function (namely, implicit
conversion sequence) B& to (const) B&.

And, Z& -> const Z& is NOT a qualification adjustment.
4.4 (Qualification conversion) refers to POINTERS only.
Z& -> const Z& is just a binding. (Read 8.5.3/5 again.)

> In this case there is another problem:
>
> struct X {
>    void f();
>    void f() const;
> };
>
> main()
> {
>    X b;
>
>    b.f(); // ambiguous ?
> }
>
> This would be ambiguous, since the implicit object parameter has type X & and the
> two functions f would take const X& and X& as implicit object parameter, both
> being direct reference bindings and according to 13.3.3.1.4 identical.

I agree that 13.3.1.4 can't distinguish them.
But 13.3.3.2/3 gives closer distinction.
That's all.
They are NOT inconsistent.

> I have the impression, that there might be an error in 13.3.3.1.4, since it omits
> cv-qualification. Therefore there are several resulting questions:
>
> - does 13.3.3.1.4 apply when comparing conversion sequences (it is not mentioned in 13.3.3.2)
> - if it does apply, is there a path converting const Z& -> Z&?

13.3.3.1.x subclauses just DEFINE implicit conversion sequences.
The way to COMPARE them is defined in 13.3.3.2 for the first time.

>
> Overall I think 13.3.3.1.4 does not apply when comparing conversion sequences
> since:
> - it is not mentioned in 13.3.3.2 (all other conversions 13.3.3.1.1, 13.3.3.1.2 and
>   13.3.3.1.3 are mentioned)

I don't understand what you mean.
After 13.3.3.1.x define ICS's, 13.3.3.2 gives their ordering.
That's all.

> - it contradicts rule 13.3.3.2/3 "S1 and S2 are reference bindings (8.5.2) ...."

That is one of 13.3.3.2 rules.
NO CONTRADICTION as you think.


As I wrote above, you seem still trying to convert the RESULT (of the
conversion by conversion function) by implicit conversion sequence.
That is not correct.

B b;
const Z& b2 = b;

As for B::operator Z&(), B to B& (which is (implicit) parameter of B::operator
Z&()) is where we should consider implicit conversion sequence.
In this case, it's an identity conversion.
The result of the conversion by the conversion function has type of Z&.
Maybe you say it will be "converted" to const Z&, but 8.5.3/5 doesn't say so.
b2 is just BOUND to the result lvalue (if this is the best viable).
b2 is NOT a parameter of any function, no implicit conversion sequences here.


Show us the order you apply these subclauses (8.5.3, 13.3.3.1.4, 13.3.3.2, ...etc).



Hideaki Onaru

---
[ 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 <francis@robinton.demon.co.uk> writes:

|>  In article <8f5bc7$suc$1@nnrp1.deja.com>, Jim Hyslop
|>  <jim.hyslop@leitch.com> writes
|>  >Oh, no - if you've given up, what hope does a mere mortal like me ha=
ve?
|>  >:-)

|>  >Actually, having been forced to study the rules more closely in
|>  >order to defend my position against Hideaki Onaru's relentless
|>  >insistence (a defense I ultimately abandoned because I was wrong)
|>  >the overload resolution process isn't so bad.  'Course, if I study
|>  >it some more to try and understand more of it, I may join you :-)

|>  I have for long argued that more calls of ambiguity and a less fine
|>  grained overload resolution would be helpful to the programmer.
|>  OTOH if you are correctly using the concept of overloading, why
|>  should it matter because all the overloads will do the same thing,
|>  just from different starting points.  Think about that the next time
|>  you write an overload, if the new version is not semantically the
|>  same as the old perhaps you should not be writing an overload.

Hear, Hear.  I find it impossible (for me, at least) to really
understant the exact details of overloading.  On the other hand, I
regularly use it without any problem.  And in some cases, I haven't the
slightest idea which function the compiler is actually calling (or even
if all compilers agree).

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Alain Miniussi <alainm@cup.hp.com> writes:

|>  > I have for long argued that more calls of ambiguity and a less
|>  > fine grained overload resolution would be helpful to the
|>  > programmer.  OTOH if you are correctly using the concept of
|>  > overloading, why should it matter because all the overloads will
|>  > do the same thing, just from different starting points.  Think
|>  > about that the next time you write an overload, if the new version
|>  > is not semantically the same as the old perhaps you should not be
|>  > writing an overload.

|>  That's true, except that you don't choose the name of your
|>  constructors so I guess the issue is still here (even if restricted
|>  to that situation).

In such cases, I've found dummy types to distinguist to be quite
helpful.  Rather than:

    X::X( double ) :
    X::X( void* ) ;

(which is ambiguous for 0, I think):

    enum ANumber { number } ;
    enum APointer { pointer } ;

    X::X( ANumber , double ) ;
    X::X( APointer , void* ) ;

The first parameter is in fact a dummy, and the constructor code never
uses it, but

    X( number , 0 )
    X( pointer , 0 )

are both perfectly unambiguous, and even the most na=EFve reader
understands which function will be called.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Matthias Meixner wrote:
>
> In my version of the standard it says "see 8.5, 13.3.1.5 and 13.3.1.6", so
> 13.3.1.6 is explicitely mentioned. (I have only got the final draft of the
> standard, so if they have taken this out in the standard, I am wrong here.)

As Jim Hyslop wrote, 13.3.1.6 is not memtioned here in the final Standard.

> Probably the whole problem arises from an ambiguity in the standard.
>
> 13.3.3.2, which deals with the ranking of conversion sequences says "standard conversion
> sequence S1 is a better conversion sequence than standard conversion S2, if
> S1 is a prober subsequence of S2", therefore  const Z& ->const Z& (identity)
> is a better conversion sequence than Z& -> const Z&.

I don't understand how you can say that const Z& -> const Z& is a proper
subsequence of Z& -> const Z& (13.3.3.2/3 says that identity conversion
sequence is considered to be a subsequence of any NON-IDENTITY conversion
sequence, but in this case, both sequences are identity conversion sequences).

> However 13.3.1.4 omits the cv-qualification and says the conversion of references is
> identity.
>
> However this would allow the following standard conversion:  const Z& -> Z&
> (13.3.1.5 would be no help in this regard, since it explicitely ignores
> cv-qualification for conversion functions.)

When do you need such a standard conversion const Z& -> Z& ?

When you'd like to initialize reference Z& by an expression of type const Z
(as an example you wrote), you have to check whether the binding is direct or
not (see 8.5.3/5).
There are two possibilities of direct binding: the reference is bound directly
to the initializer expression (whose type is const Z), or, the reference is
bound to the lvalue result of conversion by conversion function selected
through overload resolution.
This is not the case of the first possobility, because "Z&" is not
reference-compatible with "const Z&".
If a parameter of a viable conversion function selected by 13.3.1.6 has a type
of Z&, you have to go back to 8.5.3 again to check whether the binding of the
PARAMETER OF THE CONVERSION FUNCTION is direct or not.
(This could be circular: this might be a defect of the Standard.)
Anyway, "standard conversion" const Z& -> Z& is not considered.

I think you should consider the CONTEXT 13.3.3.1.4 applies and distinguish an
initialization of the reference to be initialized and that of a parameter of
the conversion function.


Hideaki Onaru

---
[ 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              ]

I wrote:

> If a parameter of a viable conversion function selected by 13.3.1.6 has a type
> of Z&, (...)        ^^^^^^

but I had to write "candidate conversion function".
                    ^^^^^^^^^

Hideaki Onaru

---
[ 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              ]

Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
) Matthias Meixner wrote:
) >
) > In my version of the standard it says "see 8.5, 13.3.1.5 and 13.3.1.6", so
) > 13.3.1.6 is explicitely mentioned. (I have only got the final draft of the
) > standard, so if they have taken this out in the standard, I am wrong here.)
)
) As Jim Hyslop wrote, 13.3.1.6 is not memtioned here in the final Standard.
)
) > Probably the whole problem arises from an ambiguity in the standard.
) >
) > 13.3.3.2, which deals with the ranking of conversion sequences says "standard conversion
) > sequence S1 is a better conversion sequence than standard conversion S2, if
) > S1 is a prober subsequence of S2", therefore  const Z& ->const Z& (identity)
) > is a better conversion sequence than Z& -> const Z&.
)
) I don't understand how you can say that const Z& -> const Z& is a proper
) subsequence of Z& -> const Z& (13.3.3.2/3 says that identity conversion
) sequence is considered to be a subsequence of any NON-IDENTITY conversion
) sequence, but in this case, both sequences are identity conversion sequences).

The question is: does 13.3.3.1.4 apply in this case?
If no:  Z& -> const Z& is a qualification adjustment, i.e. no identity conversion
If yes: Z& -> const Z& is an identity conversion.

In this case there is another problem:

struct X {
   void f();
   void f() const;
};

main()
{
   X b;

   b.f(); // ambiguous ?
}

This would be ambiguous, since the implicit object parameter has type X & and the
two functions f would take const X& and X& as implicit object parameter, both
being direct reference bindings and according to 13.3.3.1.4 identical.

However 13.3.3.2/3 rule "S1 and S2 are reference bindings ..." chooses X::f(),
so in this case 13.3.3.1.4 does not seem to apply.


)
) > However 13.3.1.4 omits the cv-qualification and says the conversion of references is
) > identity.

Just to note: I meant 13.3.3.1.4.

) >
) > However this would allow the following standard conversion:  const Z& -> Z&
) > (13.3.1.5 would be no help in this regard, since it explicitely ignores
) > cv-qualification for conversion functions.)
)
) When do you need such a standard conversion const Z& -> Z& ?

I have the impression, that there might be an error in 13.3.3.1.4, since it omits
cv-qualification. Therefore there are several resulting questions:

- does 13.3.3.1.4 apply when comparing conversion sequences (it is not mentioned in 13.3.3.2)
- if it does apply, is there a path converting const Z& -> Z&?

If this path does exist, then this would mean having a major problem. So in this
case 13.3.3.1.4 would definitely be broken and need to be fixed.

How would a fix look like? It probably would need to consider cv-qualification.
And thus having effect on comparing of conversion sequences.

However, this is speculative.

-----------------------------------------------------------------


Overall I think 13.3.3.1.4 does not apply when comparing conversion sequences
since:
- it is not mentioned in 13.3.3.2 (all other conversions 13.3.3.1.1, 13.3.3.1.2 and
  13.3.3.1.3 are mentioned)
- it contradicts rule 13.3.3.2/3 "S1 and S2 are reference bindings (8.5.2) ...."



-- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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 <86hfcb4dh4.fsf@gabi-soft.de>,
  kanze@gabi-soft.de wrote:
[snip]
> I won't argue.  I've given up trying to understand the rules for
> overloading -- they're far too complicated for me.
Oh, no - if you've given up, what hope does a mere mortal like me have?
:-)

Actually, having been forced to study the rules more closely in order to
defend my position against Hideaki Onaru's relentless insistence (a
defense I ultimately abandoned because I was wrong) the overload
resolution process isn't so bad.  'Course, if I study it some more to
try and understand more of it, I may join you :-)

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
) Matthias Meixner wrote:
) >
) > Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
) >
) > )
) > ) step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but the
) > ) bullet "the context is an initialization by user-defined conversion (see 8.5,
) > ) 13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)
) > )
) >
) > Why should this not apply? 13.3.1.6 does apply and it is also mentioned in this bullet.
) > "Under the conditionss specified in 8.5.3, a reference can be bound directly to an
) > lvalue that is the result of applying a conversion function to an initializer expression. ..."
) >
) > Therefore 13.3.3.2/3 is used to compare the standard conversion sequences, that convert
) > the output of the user defined conversion function to the type of the actual parameter.
) > And in this regard (2) has the better second standard conversion than (1).
)
) I don't understand what you mean by "the actual parameter".

The parameter of the default constructor used to initialize the reference. (Yes the
initialization does not call what you would call constructor in C++ terms, but from
an OOP point of view you would.)

) In this case, the functions under consideration are the conversion functions (1)-(3).
) Their parameters are of type (const) B&, and I mentioned that in step 1-3).
) The implicit conversion sequence we have to deal with is conversion to (const)
) B&, not the whole conversion to const Z&.
)
) "An implicit conversion sequence is a sequence of conversion used to convert
) an argument in a function call to the type of the corresponding parameter of
) the function being called." (13.3.3.1/1)
)
)
) Anyway, here I note two matters.
)
)
) 1) (about 13.3.3/1)
)
) I think that the bullet at issue in 13.3.3/1 refers only to 13.3.1.5 cases,
) not to 13.3.1.4 nor 13.3.1.6 cases, because of the comment in parentheses :
) "see 8.5, 13.3.1.5".

In my version of the standard it says "see 8.5, 13.3.1.5 and 13.3.1.6", so
13.3.1.6 is explicitely mentioned. (I have only got the final draft of the
standard, so if they have taken this out in the standard, I am wrong here.)

) 13.3.1.6 does say that conversion function is considered, but it's not the
) case of 13.3.1.5.
) (The reason why only 13.3.1.5 is referred to here is because only 13.3.1.5
) refers to standard conversion sequence after conversion by conversion
) function, I think:
)
) "The conversion function of S and its base classes are considered. Those that
) are not hidden within S and yield type T or a type that can be converted to
) type T via a standard conversion sequence are candidate functions. (...)" (13.3.1.5/1))
)
)
) 2) (about "standard conversion" from (const) Z& to const Z&)
)
) In direct binding cases, there is no CONVERSION which CONVERTS (the result of
) the conversion of) the initializer expression to the reference type which is initialized.
) ("Derived-to-base Conversion" is considered in parameter cases only. Moreover,
) as noted in 13.3.3.1/6, there is no such conversion, but it exists only in the
) description of implicit conversion sequence. And no "Qualification Conversion"
) is considered anyway, even in descripitive meaning. See 13.3.3.1.4.)
)
) Consider the following simple example:
)
) class B {};
) class D : public B {};
)
) D d, d0;
) D& rd = d;
) const B& rcb = rd;
)
) rd is bound to non-const d.
) rcb is bound to what rd is bound to, namely, d.
) ("const B&" is reference-compatible with "D&", so this is the case of
) first sub-bullet of first bullet in 8.5.3/5.)
) Here, rd is not CONVERTED to const B&, nor is d.
) rcb is just BOUND to (non-const) d.
) (Even descriptive "derived-to-base Conversion" is not considered.)
) d is not CONST type, but the type of rcb tells us not to change the value
) through rcb:
)
) rd = d0;    // well-formed
) rcb = d0;   // ill-formed
)
) In our case, b2 would be bound to the result of conversion function, if the
) overload resolution succeeded, as described in 8.5.3/5.
) But, in that case anyway, no (actual nor descriptive) CONVERSION would be
) needed.
)


Probably the whole problem arises from an ambiguity in the standard.

13.3.3.2, which deals with the ranking of conversion sequences says "standard conversion
sequence S1 is a better conversion sequence than standard conversion S2, if
S1 is a prober subsequence of S2", therefore  const Z& ->const Z& (identity)
is a better conversion sequence than Z& -> const Z&.

However 13.3.1.4 omits the cv-qualification and says the conversion of references is
identity.

However this would allow the following standard conversion:  const Z& -> Z&
(13.3.1.5 would be no help in this regard, since it explicitely ignores
cv-qualification for conversion functions.)

This would contradict 8.5.3/4-6

So according to your argumentation probably the following example could be valid code:

const Z a;
Z &b=a;

Although b cannot be initialized by const Z&, 13.3.1.4 gives a standard conversion
from const Z& to Z&, which in turn can be used to initialize b.

This would be a bad thing.

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701



---
[ 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 <8f61s8$sd3$1@sun27.hrz.tu-darmstadt.de>,
  meixner@rbg.informatik.tu-darmstadt.de (Matthias Meixner) wrote:
> Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
[snip]
> ) 1) (about 13.3.3/1)
> )
> ) I think that the bullet at issue in 13.3.3/1 refers only to 13.3.1.5
cases,
> ) not to 13.3.1.4 nor 13.3.1.6 cases, because of the comment in
parentheses :
> ) "see 8.5, 13.3.1.5".
>
> In my version of the standard it says "see 8.5, 13.3.1.5 and
> 13.3.1.6", so
> 13.3.1.6 is explicitely mentioned. (I have only got the final draft of
> the
> standard, so if they have taken this out in the standard, I am wrong
> here.)
The reference to 13.3.1.6 has been removed in the official standard.

[snip]
> Probably the whole problem arises from an ambiguity in the standard.
[snip]
> So according to your argumentation probably the following example
> could be valid code:
>
> const Z a;
> Z &b=a;
>
> Although b cannot be initialized by const Z&, 13.3.1.4 gives a
> standard conversion
> from const Z& to Z&, which in turn can be used to initialize b.
But according to 13.3 para 2, 13.3.1.4 only applies to the
initialization of *class* objects - a reference is not a class object,
so 13.3.1.4 does not apply in this case.  You would have to have:

const Z a;
Z b=a;

which is fine - you are initializing a non-const object from a const
object.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <3913ABCF.50888DBC@mx1.ttcn.ne.jp>,
  gomarine@mx1.ttcn.ne.jp wrote:
> Jim Hyslop wrote:
> >
> > BTW, In answer to your earlier statement about whether your steps
(2)
> > through (2-6) are required, I don't think so.  I think, given the
> > statements:
> >
> > B b;
> > const Z& b2=b;
> >
> > the compiler will first check the rules in 8.3.5/5, discover that T1
> > is
> > not reference compatible with T2, then follow the second bullet and
> > attempt to implicitly convert T2 (b) to an lvalue, which will result
> > in
> > the overloading lookup we've been discussing.
>
> This overload resolution fails, as steps 1) through 1-7).
> "Second bullet" you say is second sub-bullet of first bullet at page
> 147.
> "Second bullet" I say in step 2) is not the sub-bullet, but the bullet
> at page 148:
Yikes!  This whole thing would be less confusing if the bullets were
numbered instead!

> "- Otherwise, the reference shall be to a non-volatile const type
> (i.e., cv1
> shall be const). (...)"
>
> I thought this "otherwise" includes our case (that is, the case where
> THERE
> ARE several viable conversion functions BUT overload resolution
> fails), so I
> added the steps 2) and 2-n).
Ah, I see what you're getting at.  Ummm... let's see.  Yes, I think
you're right - if the two sub-bullets on p. 147 fail, then the
"Otherwise..." bullet takes effect.

> The 1st sub-bullet of the bullet
I shoulda been a lawyer!!! :-)  Sorry, you were saying:

> does not apply, because the initializer
> expression b is not an rvalue.
Agreed.

> My 2) and 2-n) steps are for 2nd sub-bullet of the bullet.
> (Another) example this sub-bullet applies is as follows:
>
> struct X {};
>
> struct Y {
>     operator X() { return X(); };
> };
>
> void f() {
>     Y y;
>     const X& rcx = y;
> }
>
> rcx is bound to a temporary created by Y::operator X().

Actually, I think the bullet you're referring to (the last bullet on
p.148) would only take effect if you overload operator X.  As your
example stands, the name lookup would succeed.

My head hurts.  :-)

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <8f5bc7$suc$1@nnrp1.deja.com>, Jim Hyslop
<jim.hyslop@leitch.com> writes
>Oh, no - if you've given up, what hope does a mere mortal like me have?
>:-)
>
>Actually, having been forced to study the rules more closely in order to
>defend my position against Hideaki Onaru's relentless insistence (a
>defense I ultimately abandoned because I was wrong) the overload
>resolution process isn't so bad.  'Course, if I study it some more to
>try and understand more of it, I may join you :-)

I have for long argued that more calls of ambiguity and a less fine
grained overload resolution would be helpful to the programmer.  OTOH if
you are correctly using the concept of overloading, why should it matter
because all the overloads will do the same thing, just from different
starting points.  Think about that the next time you write an overload,
if the new version is not semantically the same as the old perhaps you
should not be writing an overload.


Francis Glassborow      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 <8f5bc7$suc$1@nnrp1.deja.com>, Jim Hyslop
> <jim.hyslop@leitch.com> writes
> >Oh, no - if you've given up, what hope does a mere mortal like me have?
> >:-)
> >
> >Actually, having been forced to study the rules more closely in order to
> >defend my position against Hideaki Onaru's relentless insistence (a
> >defense I ultimately abandoned because I was wrong) the overload
> >resolution process isn't so bad.  'Course, if I study it some more to
> >try and understand more of it, I may join you :-)
>
> I have for long argued that more calls of ambiguity and a less fine
> grained overload resolution would be helpful to the programmer.  OTOH if
> you are correctly using the concept of overloading, why should it matter
> because all the overloads will do the same thing, just from different
> starting points.  Think about that the next time you write an overload,
> if the new version is not semantically the same as the old perhaps you
> should not be writing an overload.

That's true, except that you don't choose the name of your constructors
so
I guess the issue is still here (even if restricted to that situation).

Alain

---
[ 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              ]

Jim Hyslop (jim.hyslop@leitch.com) wrote:

[...]

) > Probably the whole problem arises from an ambiguity in the standard.
) [snip]
) > So according to your argumentation probably the following example
) > could be valid code:
) >
) > const Z a;
) > Z &b=a;
) >
) > Although b cannot be initialized by const Z&, 13.3.1.4 gives a
) > standard conversion
) > from const Z& to Z&, which in turn can be used to initialize b.
) But according to 13.3 para 2, 13.3.1.4 only applies to the

Oops, I meant 13.3.3.1.4 (omitting one 3.).

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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 <MCs2MYAgTxF5EwEG@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
[snip]
> Think about that the next time you write an
> overload,
> if the new version is not semantically the same as the old perhaps you
> should not be writing an overload.
Oops, lost sight of the forest for the trees.  Thanks, Francis.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Michael Kochetkov (mkochetk@trustworks.commm) wrote:
: Sorry, as we found out it should be
: 13.3.1.6 and 8.5.3/4,5. If they do not help I surrender :(.

This section is about selection of candidate functions and not about the
actual selection of the best viable function. So the selection of the
best function is not affected by this section.

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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              ]

Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:

[...]

) I think what Jack Rouse wrote is right.
)
)
) step 1)(8.5.3/5, 1st bullet) In order to choose the best conversion function,
)
) step 1-1)(13.3.1.6) select the candidate functions (all of (1)-(3)), and
)
) step 1-2)(13.3.2) consider implicit conversion sequences of each of (1)-(3).
)
) step 1-3)(13.3.3.1.4) Because the parameter is (const) B& and binds directly
) to the argument expression b (here we have to go back to 8.5.3 again to check
) this binding is direct or not), its implicit conversion sequence is identity
) conversion, for all of (1)-(3).
)
) (Note: no "qualification" conversion is described in 13.3.3.1.4. It says,
)
) "When a parameter of reference type binds directly to an argument expression,
) the implicit conversion sequence is the identity conversion, unless the
) aregument expression has a type that is a derived class of the parameter type,..."
)
) and "to bind directly" is defined in 8.5.3. "Reference-compatibility" subsumes
) the difference of cv-qualifiers.)
)
) step 1-4)(13.3.3.2) ICS((1)) and ICS((2)) are better conversion sequences than ICS((3)).

agreed so far.

)
) step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but the
) bullet "the context is an initialization by user-defined conversion (see 8.5,
) 13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)
)

Why should this not apply? 13.3.1.6 does apply and it is also mentioned in this bullet.
"Under the conditionss specified in 8.5.3, a reference can be bound directly to an
lvalue that is the result of applying a conversion function to an initializer expression. ..."

Therefore 13.3.3.2/3 is used to compare the standard conversion sequences, that convert
the output of the user defined conversion function to the type of the actual parameter.
And in this regard (2) has the better second standard conversion than (1).

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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 <390FD7B7.DA00BE25@mx1.ttcn.ne.jp>,
  gomarine@mx1.ttcn.ne.jp wrote:
> Jim Hyslop wrote:
> >
> > In article <8eko6l$61f$1@license1.unx.sas.com>,
> >   sasjjr@unx.sas.com (Jack Rouse) wrote:
> > >
> > > The candidate functions are:
> > >
> > > (1)   B::operator Z &();
> > > (2)   B::operator const Z &();
> > > (3)   B::operator const Z &() const;
> > >
> > > Candidates (1) and (2) are better than (3) because of the
> > > qualification of the object parameter.  So according to the point
> > > mentioned above, overload resolution compares the standard
conversion
> > > sequences on the return types:
> > >
> > > (1)  Z& -> const Z&
> > > (2)  const Z& -> const Z&
> > >
> > > Both are reference bindings which are identity conversions.  The
> > > target types are the same so the rules for ranking standard
> > > conversions don't provide an order here.
> > No, the targe types are not the same - (1) is non-const, (2) is
const.
> > "const & to const &" is a better sequence than "const & to non-const
&".
> > Re-read the section that James Kanze mentioned.
>
> I think what Jack Rouse wrote is right.
[snip steps we agree on]
At this point (3) has been eliminated from consideration.

> step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but
> the
> bullet "the context is an initialization by user-defined conversion
> (see 8.5,
> 13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)
Ah, but it does apply.  Here is the complete bullet:

"the context is an initialization by user-defined conversion ... and the
standard conversion sequence of the return type of F1 to the destination
type (i.e. the type of the entity being initialized) is a better
conversion sequence than the standard conversion sequence from the
return type of F2 to the destination type."

Examining this point by point:
Is this an initialization by user-defined conversion?  Absolutely, since
it is the initialization of a Z object by using the user-defined
conversion operators declared in B.

Is the standard conversion sequence (etc.) of F1 better than the
standard (etc.) of F2?

Remember, the line in question is:

B b;
const Z & b2=b;

so the entity being initialized is a const Z &.

F1 returns a Z&, which must be converted to a const Z&.
F2 returns a const Z&, which does not require conversion.

13.3.3.2/3 states that, given conversion sequences S1 and S2, S1 is a
better sequence than 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...."

Bingo!  Our S1 is an Qualification Adjustment, S2 is an Identity
Conversion.  That makes our S2 a subsequence of S1, therefore S2 is
better than S1, therefore F2 (the one that returns a const reference) is
the best viable function and the program is well-formed.

[snip]
> I'm not sure these steps 2) and 2-n) are necessary or not.
> For example,
>
> struct B{
>
>     int i;
>
>     operator int&() { return i; }
>     operator const int&() { return i; }
>     operator const int&() const { return i; }
>
> };
>
> void f(){
>     B         b;
>     const B  cb;
>
>     int&       rib   = b;
>     const int& rcib  = b;
>     const int& rcicb = cb;
> }
This is well-formed, for exactly the same reasons.  After all, the code
is identical except for the types involved.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Matthias Meixner wrote:
>
> Hideaki Onaru (gomarine@mx1.ttcn.ne.jp) wrote:
>
> )
> ) step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but the
> ) bullet "the context is an initialization by user-defined conversion (see 8.5,
> ) 13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)
> )
>
> Why should this not apply? 13.3.1.6 does apply and it is also mentioned in this bullet.
> "Under the conditionss specified in 8.5.3, a reference can be bound directly to an
> lvalue that is the result of applying a conversion function to an initializer expression. ..."
>
> Therefore 13.3.3.2/3 is used to compare the standard conversion sequences, that convert
> the output of the user defined conversion function to the type of the actual parameter.
> And in this regard (2) has the better second standard conversion than (1).

I don't understand what you mean by "the actual parameter".
In this case, the functions under consideration are the conversion functions (1)-(3).
Their parameters are of type (const) B&, and I mentioned that in step 1-3).
The implicit conversion sequence we have to deal with is conversion to (const)
B&, not the whole conversion to const Z&.

"An implicit conversion sequence is a sequence of conversion used to convert
an argument in a function call to the type of the corresponding parameter of
the function being called." (13.3.3.1/1)


Anyway, here I note two matters.


1) (about 13.3.3/1)

I think that the bullet at issue in 13.3.3/1 refers only to 13.3.1.5 cases,
not to 13.3.1.4 nor 13.3.1.6 cases, because of the comment in parentheses :
"see 8.5, 13.3.1.5".
13.3.1.6 does say that conversion function is considered, but it's not the
case of 13.3.1.5.
(The reason why only 13.3.1.5 is referred to here is because only 13.3.1.5
refers to standard conversion sequence after conversion by conversion
function, I think:

"The conversion function of S and its base classes are considered. Those that
are not hidden within S and yield type T or a type that can be converted to
type T via a standard conversion sequence are candidate functions. (...)" (13.3.1.5/1))


2) (about "standard conversion" from (const) Z& to const Z&)

In direct binding cases, there is no CONVERSION which CONVERTS (the result of
the conversion of) the initializer expression to the reference type which is initialized.
("Derived-to-base Conversion" is considered in parameter cases only. Moreover,
as noted in 13.3.3.1/6, there is no such conversion, but it exists only in the
description of implicit conversion sequence. And no "Qualification Conversion"
is considered anyway, even in descripitive meaning. See 13.3.3.1.4.)

Consider the following simple example:

class B {};
class D : public B {};

D d, d0;
D& rd = d;
const B& rcb = rd;

rd is bound to non-const d.
rcb is bound to what rd is bound to, namely, d.
("const B&" is reference-compatible with "D&", so this is the case of
first sub-bullet of first bullet in 8.5.3/5.)
Here, rd is not CONVERTED to const B&, nor is d.
rcb is just BOUND to (non-const) d.
(Even descriptive "derived-to-base Conversion" is not considered.)
d is not CONST type, but the type of rcb tells us not to change the value
through rcb:

rd = d0;    // well-formed
rcb = d0;   // ill-formed

In our case, b2 would be bound to the result of conversion function, if the
overload resolution succeeded, as described in 8.5.3/5.
But, in that case anyway, no (actual nor descriptive) CONVERSION would be
needed.


Hideaki Onaru

---
[ 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              ]

Jim Hyslop wrote:
>
> In article <390FD7B7.DA00BE25@mx1.ttcn.ne.jp>,
>   gomarine@mx1.ttcn.ne.jp wrote:
>
> > step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but
> > the
> > bullet "the context is an initialization by user-defined conversion
> > (see 8.5,
> > 13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)
> Ah, but it does apply.  Here is the complete bullet:
>
> "the context is an initialization by user-defined conversion ... and the
> standard conversion sequence of the return type of F1 to the destination
> type (i.e. the type of the entity being initialized) is a better
> conversion sequence than the standard conversion sequence from the
> return type of F2 to the destination type."
>
> Examining this point by point:
> Is this an initialization by user-defined conversion?  Absolutely, since
> it is the initialization of a Z object by using the user-defined
> conversion operators declared in B.
It is initialized by user-defined conversion, but not the case of 13.3.1.5.
That's the point.

> Is the standard conversion sequence (etc.) of F1 better than the
> standard (etc.) of F2?
>
> Remember, the line in question is:
>
> B b;
> const Z & b2=b;
>
> so the entity being initialized is a const Z &.
>
> F1 returns a Z&, which must be converted to a const Z&.
There is no such a CONVERSION from Z& to const Z&.
b2 is just BOUND to what the result of conversion function refers to, as
described in 8.5.3/5.

> F2 returns a const Z&, which does not require conversion.
"Does not require conversion" is not the exact description for this case.
In this 13.3.1.4 case, no (standard) coversion after conversion by conversion
function is considered from the beginning.
As for 13.3.1.5, which is referred to in the bullet of 13.3.3/1, the Standard
clearly says that such conversion is considered:

"The conversion function of S and its base classes are considered. Those that
are not hidden within S and yield type T or a type that can be converted
totype T via a standard conversion sequence are candidate functions. (...)" (13.3.1.5/1)

> 13.3.3.2/3 states that, given conversion sequences S1 and S2, S1 is a
> better sequence than 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...."
>
> Bingo!  Our S1 is an Qualification Adjustment, S2 is an Identity
> Conversion.  That makes our S2 a subsequence of S1, therefore S2 is
> better than S1, therefore F2 (the one that returns a const reference) is
> the best viable function and the program is well-formed.
You are saying about "conversion" AFTER the conversion by conversion function.
But,

"An implicit conversion sequence is a sequence of conversion used to convert
an argument in a function call to the type of the corresponding parameter of
the function being called." (13.3.3.1/1)

The function we consider in this case is conversion function, so implicit
conversion sequence to be considered is direct binding of B& to b, that is
identity conversion as described in 13.3.3.1.4 (and step 1-3)).
After-conversion-function-conversion is not considered in this case, as I
wrote above.
And, 4.4 (Qualification conversions) doesn't refers to reference cases.


Hideaki Onaru

---
[ 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 <3912ECF5.8EEB89CD@mx1.ttcn.ne.jp>,
  gomarine@mx1.ttcn.ne.jp wrote:
[snip]
> It is initialized by user-defined conversion, but not the case of
> 13.3.1.5.
> That's the point.
Yep, you're right.  It's ill-formed.  I sat down and worked through the
rules, in order, and followed your earlier steps very carefully.

Whew, such subtleties to trap the unwary!

BTW, In answer to your earlier statement about whether your steps (2)
through (2-6) are required, I don't think so.  I think, given the
statements:

B b;
const Z& b2=b;

the compiler will first check the rules in 8.3.5/5, discover that T1 is
not reference compatible with T2, then follow the second bullet and
attempt to implicitly convert T2 (b) to an lvalue, which will result in
the overloading lookup we've been discussing.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Jim Hyslop wrote:
>
> BTW, In answer to your earlier statement about whether your steps (2)
> through (2-6) are required, I don't think so.  I think, given the
> statements:
>
> B b;
> const Z& b2=b;
>
> the compiler will first check the rules in 8.3.5/5, discover that T1 is
> not reference compatible with T2, then follow the second bullet and
> attempt to implicitly convert T2 (b) to an lvalue, which will result in
> the overloading lookup we've been discussing.

This overload resolution fails, as steps 1) through 1-7).
"Second bullet" you say is second sub-bullet of first bullet at page 147.
"Second bullet" I say in step 2) is not the sub-bullet, but the bullet at page 148:

"- Otherwise, the reference shall be to a non-volatile const type (i.e., cv1
shall be const). (...)"

I thought this "otherwise" includes our case (that is, the case where THERE
ARE several viable conversion functions BUT overload resolution fails), so I
added the steps 2) and 2-n).
The 1st sub-bullet of the bullet does not apply, because the initializer
expression b is not an rvalue.
My 2) and 2-n) steps are for 2nd sub-bullet of the bullet.
(Another) example this sub-bullet applies is as follows:

struct X {};

struct Y {
    operator X() { return X(); };
};

void f() {
    Y y;
    const X& rcx = y;
}

rcx is bound to a temporary created by Y::operator X().


Hideaki Onaru

---
[ 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              ]

jsa@edg.com (J. Stephen Adamczyk) writes:

|>  In article <86bt2qttc2.fsf@gabi-soft.de> kanze@gabi-soft.de writes:
|>  >|>  Still, the original code is invalid. The conflict is between
|>  >|>  the "Z&()" and "const Z&()" operators. (See the post by Jim
|>  >|>  Hyslop.  Thanks Jim!)

|>  >Except perhaps, for 13.3.3: the third point of the second bulleted
|>  >list states: "the context is an initialization by user-defined
|>  >conversion and the standard conversion sequence from the return
|>  >type of F1 to the destination type (i.e., the type of the entity
|>  >being initialized) is a better conversion sequence than the
|>  >standard conversion sequence from the return type of F2 to the
|>  >destination type."  This is one of the rare cases where the result
|>  >type enters into overload resolution.

|>  Yes, but take a look at 13.3.3.1.4 paragraph 1, second half.  In a
|>  case where a reference binds directly to the result of a conversion
|>  function, there is no "conversion" on the return type (except
|>  possibly a derived-to-base conversion, which doesn't apply in this
|>  case).  So both conversions have a second standard conversion
|>  sequence that is identity, and therefore they are indistinguishable.

I won't argue.  I've given up trying to understand the rules for
overloading -- they're far too complicated for me.  I just happened to
remember this point from an earlier thread, and it seemed like it was
being ignored.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

"Biju Thomas" <b.thomas@attglobal.net> wrote in message
news:3909C77B.9F5B427C@attglobal.net...
[snip]
>
> No, the code is not ok. Both the const and non-const "const Z&"
> operators are viable in the statement:
>
>   const Z& b2 = b;
>

I guess you meant:
operator Z &() { puts("ba"); return x; }
and
operator const Z &() { puts("bb"); return x; }
are viable.
It's true, but one of them is better than the other. Non-const version
requires const qualification conversion on return value and therefore is
worse than operator that return const Z&.
--
Gene Bushuyev
*** If Linux is the answer, then what is the question? ***



---
[ 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 <86bt2qttc2.fsf@gabi-soft.de>,
  kanze@gabi-soft.de wrote:
[snip]
> Except perhaps, for 13.3.3: the third point of the second bulleted
> list
> states: "the context is an initialization by user-defined conversion
> and
> the standard conversion sequence from the return type of F1 to the
> destination type (i.e., the type of the entity being initialized) is a
> better conversion sequence than the standard conversion sequence from
> the return type of F2 to the destination type."  This is one of the
> rare
> cases where the result type enters into overload resolution.
Ah, missed that one - so the code is, in fact, well-formed, and MSVC got
it right, too.

Gotta study that section some more, I guess ;-)

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <86bt2qttc2.fsf@gabi-soft.de> kanze@gabi-soft.de writes:

>Except perhaps, for 13.3.3: the third point of the second bulleted list
>states: "the context is an initialization by user-defined conversion and
>the standard conversion sequence from the return type of F1 to the
>destination type (i.e., the type of the entity being initialized) is a
>better conversion sequence than the standard conversion sequence from
>the return type of F2 to the destination type."  This is one of the rare
>cases where the result type enters into overload resolution.

If you examine the rules for comparing the standard conversion
sequences on the return type then I believe you will find the
conversions are unordered in this case.

The candidate functions are:

(1)   B::operator Z &();
(2)   B::operator const Z &();
(3)   B::operator const Z &() const;

Candidates (1) and (2) are better than (3) because of the
qualification of the object parameter.  So according to the point
mentioned above, overload resolution compares the standard conversion
sequences on the return types:

(1)  Z& -> const Z&
(2)  const Z& -> const Z&

Both are reference bindings which are identity conversions.  The
target types are the same so the rules for ranking standard
conversions don't provide an order here.

--
Jack Rouse
Jack.Rouse@sas.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 <8eko6l$61f$1@license1.unx.sas.com>,
  sasjjr@unx.sas.com (Jack Rouse) wrote:
> In <86bt2qttc2.fsf@gabi-soft.de> kanze@gabi-soft.de writes:
>
> >Except perhaps, for 13.3.3: the third point of the second bulleted
list
> >states: "the context is an initialization by user-defined conversion
and
> >the standard conversion sequence from the return type of F1 to the
> >destination type (i.e., the type of the entity being initialized) is
a
> >better conversion sequence than the standard conversion sequence from
> >the return type of F2 to the destination type."  This is one of the
rare
> >cases where the result type enters into overload resolution.
>
> If you examine the rules for comparing the standard conversion
> sequences on the return type then I believe you will find the
> conversions are unordered in this case.
>
> The candidate functions are:
>
> (1)   B::operator Z &();
> (2)   B::operator const Z &();
> (3)   B::operator const Z &() const;
>
> Candidates (1) and (2) are better than (3) because of the
> qualification of the object parameter.  So according to the point
> mentioned above, overload resolution compares the standard conversion
> sequences on the return types:
>
> (1)  Z& -> const Z&
> (2)  const Z& -> const Z&
>
> Both are reference bindings which are identity conversions.  The
> target types are the same so the rules for ranking standard
> conversions don't provide an order here.
No, the targe types are not the same - (1) is non-const, (2) is const.
"const & to const &" is a better sequence than "const & to non-const &".
Re-read the section that James Kanze mentioned.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

See the rest of the thread for details on whether the code is right or
wrong.

Just as a point of interest, MS Visual C++ 6.0 compiles the code
without the error.


On Sat, 29 Apr 2000 02:22:48 CST,
meixner@rbg.informatik.tu-darmstadt.de (Matthias Meixner) wrote:

>Hello,
>
>I have got the following short test:
>
>#include <stdio.h>
>
>struct Z { Z(){} };
>
>struct B {
>   Z x;
>
>   operator Z &() { puts("ba"); return x; }
>   operator const Z &() { puts("bb"); return x; }
>   operator const Z &() const { puts("bc"); return x; }
>};
>
>main()
>{
>   B b;
>   const B cb;
>   Z &b1=b;
>   const Z &b2=b;
>   const Z &b3=cb;
>
>}
>
>This code was compiled using 4 different compilers. Two of which compile
>without problems, whereas the other two claim that the "conversion from
>`B' to `const Z &' is ambiguous".
>
>The compilers tested were:
>
>gcc:                        error
>comeau C++ (WWW compiler):  error
>Sun Workshop PRO 5.0:       ok
>Borland C++:                ok
>
>So which compilers are right and which have an error? I believe that the
>code is ok.
>
>Can someone else probably test some other compilers and report the results?
>
>- Matthias Meixner

---
[ 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 <Ftvwu0.L1D@edg.com>,
  jsa@edg.com (J. Stephen Adamczyk) wrote:
> In article <86bt2qttc2.fsf@gabi-soft.de> kanze@gabi-soft.de writes:
> >|>  Still, the original code is invalid. The conflict is between
> >|>  the "Z&()" and "const Z&()" operators. (See the post by Jim
> >|>  Hyslop.
> >|>  Thanks Jim!)
> >
> >Except perhaps, for 13.3.3: the third point of the second bulleted
[snip]
> Yes, but take a look at 13.3.3.1.4 paragraph 1, second half.
This clause does not apply, because it discusses the binding of
parameters, not return values.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Matthias Meixner (meixner@rbg.informatik.tu-darmstadt.de) wrote:
: The compilers tested were:
:
: gcc:                        error
: comeau C++ (WWW compiler):  error
: Sun Workshop PRO 5.0:       ok
: Borland C++:                ok
:
: So which compilers are right and which have an error? I believe that the
: code is ok.
:
: Can someone else probably test some other compilers and report the results?

In the meantime I got some additional results:

HP-UX 11 ANSI C++ Compiler:   ok
Microsoft Visual C++:         ok

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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              ]

"Gene Bushuyev" <gbush@my-deja.com> wrote in message
news:0a9b25442171e40CPIMSSMTPE01@msn.com...
[snip]
> I guess you meant:
> operator Z &() { puts("ba"); return x; }
> and
> operator const Z &() { puts("bb"); return x; }
> are viable.
> It's true, but one of them is better than the other. Non-const version
> requires const qualification conversion on return value and therefore is
> worse than operator that return const Z&.

Repent, and pour ashes upon my head. Apparently, the first conversion
operator can be directly bound to the const reference, that makes an
identity conversion. These two conversion functions are ambiguous indeed. My
apology.

--
Gene Bushuyev
*** If Linux is the answer, then what is the question? ***



---
[ 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              ]

"Jim Hyslop" <jim.hyslop@leitch.com> wrote in message
news:8ek7bt$99h$1@nnrp1.deja.com...
> In article <86bt2qttc2.fsf@gabi-soft.de>,
>   kanze@gabi-soft.de wrote:
> [snip]
> > Except perhaps, for 13.3.3: the third point of the second bulleted
> > list
> > states: "the context is an initialization by user-defined conversion
> > and
> > the standard conversion sequence from the return type of F1 to the
> > destination type (i.e., the type of the entity being initialized) is a
> > better conversion sequence than the standard conversion sequence from
> > the return type of F2 to the destination type."  This is one of the
> > rare
> > cases where the result type enters into overload resolution.
> Ah, missed that one - so the code is, in fact, well-formed, and MSVC got
> it right, too.
>
> Gotta study that section some more, I guess ;-)
And this one ;)
13.3.1.5/1 "Conversion functions that return a cv-qualified type are
considered  to  yield the cv-unqualified version of that type for this
process of selecting candidate functions."

With regards,
Michael Kochetkov.



>
> --
> Jim
> I ignore all email from recruitment agencies.  Except that
> I reserve the right to send rude, nasty replies to recruiters.
> Please do not send me email with questions - post
> here.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
> ---
> [ 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              ]
>




---
[ 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              ]

Sorry, as we found out it should be
13.3.1.6 and 8.5.3/4,5. If they do not help I surrender :(.

With regards,
Michael Kochetkov.

"Michael Kochetkov" <mkochetk@trustworks.commm> wrote in message
news:390efc95@news.telekom.ru...
>
> "Jim Hyslop" <jim.hyslop@leitch.com> wrote in message
> news:8ek7bt$99h$1@nnrp1.deja.com...
> > In article <86bt2qttc2.fsf@gabi-soft.de>,
> >   kanze@gabi-soft.de wrote:
> > [snip]
> > > Except perhaps, for 13.3.3: the third point of the second bulleted
> > > list
> > > states: "the context is an initialization by user-defined conversion
> > > and
> > > the standard conversion sequence from the return type of F1 to the
> > > destination type (i.e., the type of the entity being initialized) is a
> > > better conversion sequence than the standard conversion sequence from
> > > the return type of F2 to the destination type."  This is one of the
> > > rare
> > > cases where the result type enters into overload resolution.
> > Ah, missed that one - so the code is, in fact, well-formed, and MSVC got
> > it right, too.
> >
> > Gotta study that section some more, I guess ;-)
> And this one ;)
> 13.3.1.5/1 "Conversion functions that return a cv-qualified type are
> considered  to  yield the cv-unqualified version of that type for this
> process of selecting candidate functions."
>
> With regards,
> Michael Kochetkov.
>
>
>
> >
> > --
> > Jim
> > I ignore all email from recruitment agencies.  Except that
> > I reserve the right to send rude, nasty replies to recruiters.
> > Please do not send me email with questions - post
> > here.
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
> > ---
> > [ comp.std.c++ is moderated.  To submit articles, try just posting
with ]
> > [ your news-reader.  If that fails, use
lto:std-c++@ncar.ucar.edu    ]
> > [              --- Please see the FAQ before
             ]
> > [ FAQ:
y.sgi.com/austern_mti/std-c++/faq.html              ]
> >
>
>
>
>
> ---
> [ 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              ]
>




---
[ 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              ]

Jim Hyslop wrote:
>
> In article <8eko6l$61f$1@license1.unx.sas.com>,
>   sasjjr@unx.sas.com (Jack Rouse) wrote:
> >
> > The candidate functions are:
> >
> > (1)   B::operator Z &();
> > (2)   B::operator const Z &();
> > (3)   B::operator const Z &() const;
> >
> > Candidates (1) and (2) are better than (3) because of the
> > qualification of the object parameter.  So according to the point
> > mentioned above, overload resolution compares the standard conversion
> > sequences on the return types:
> >
> > (1)  Z& -> const Z&
> > (2)  const Z& -> const Z&
> >
> > Both are reference bindings which are identity conversions.  The
> > target types are the same so the rules for ranking standard
> > conversions don't provide an order here.
> No, the targe types are not the same - (1) is non-const, (2) is const.
> "const & to const &" is a better sequence than "const & to non-const &".
> Re-read the section that James Kanze mentioned.


I think what Jack Rouse wrote is right.


step 1)(8.5.3/5, 1st bullet) In order to choose the best conversion function,

step 1-1)(13.3.1.6) select the candidate functions (all of (1)-(3)), and

step 1-2)(13.3.2) consider implicit conversion sequences of each of (1)-(3).

step 1-3)(13.3.3.1.4) Because the parameter is (const) B& and binds directly
to the argument expression b (here we have to go back to 8.5.3 again to check
this binding is direct or not), its implicit conversion sequence is identity
conversion, for all of (1)-(3).

(Note: no "qualification" conversion is described in 13.3.3.1.4. It says,

"When a parameter of reference type binds directly to an argument expression,
the implicit conversion sequence is the identity conversion, unless the
aregument expression has a type that is a derived class of the parameter type,..."

and "to bind directly" is defined in 8.5.3. "Reference-compatibility" subsumes
the difference of cv-qualifiers.)

step 1-4)(13.3.3.2) ICS((1)) and ICS((2)) are better conversion sequences than ICS((3)).

step 1-5)(13.3.3/1) So, (1) and (2) are better functions than (3), but the
bullet "the context is an initialization by user-defined conversion (see 8.5,
13.3.1.5) and ..." doesn't apply. (This is not the case of 13.3.1.5.)

(Note: if B doesn't have (2), (1) is the best viable and the initialization is
well-formed. in this case, the result of the conversion is "Z&" (not "const
Z&"), but b2 is bound to the resulting lvalue, without no "qualification" conversion.)

step 1-6)(13.3.3/2) Call of conversion function is ill-formed: therefore,

step 1-7)(8.5.3/5, 1st bullet) the initializer expression b can't be
implicitly converted to lvalue of type "cv3 T3", where "const Z&" is
reference-compatible with "cv3 T3", according to 13.3.1.6 and 13.3.3.

step 2)(8.5.3/5, 2nd bullet) Initializer expression b is not rvalue, so a
temporary of type "const Z" is to be created.

step 2-1)(13.3.1.4) Candidate functions are all of (1)-(3).

step 2-2)(13.3.2) Consider their implicit conversion functions:

step 2-3)(13.3.3.1.4) they are all identity conversions.

step 2-4)(13.3.3.2) ICS((1)) and ICS((2)) are better than ICS((3)).

step 2-5)(13.3.3/1) (1) and (2) are better than (3), but this is not the case
of 13.3.1.5 again.

step 2-6)(13.3.3/2) Call of conversion function to create a temporary of type
"const Z" is ill-formed.

step 3) After all, the initialization is ill-formed.


I'm not sure these steps 2) and 2-n) are necessary or not.
For example,

struct B{

    int i;

    operator int&() { return i; }
    operator const int&() { return i; }
    operator const int&() const { return i; }

};

void f(){
    B         b;
    const B  cb;

    int&       rib   = b;
    const int& rcib  = b;
    const int& rcicb = cb;
}

Initializing rcib above is

A) well-formed (a temporary is created, if steps 2) and 2-n) are executed:
this is the case of 13.3.1.5), or

B) ill-formed again (if these steps are not considered)?


Hideaki Onaru

---
[ 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              ]

Hello,

I have got the following short test:

#include <stdio.h>

struct Z { Z(){} };

struct B {
   Z x;

   operator Z &() { puts("ba"); return x; }
   operator const Z &() { puts("bb"); return x; }
   operator const Z &() const { puts("bc"); return x; }
};

main()
{
   B b;
   const B cb;
   Z &b1=b;
   const Z &b2=b;
   const Z &b3=cb;

}

This code was compiled using 4 different compilers. Two of which compile
without problems, whereas the other two claim that the "conversion from
`B' to `const Z &' is ambiguous".

The compilers tested were:

gcc:                        error
comeau C++ (WWW compiler):  error
Sun Workshop PRO 5.0:       ok
Borland C++:                ok

So which compilers are right and which have an error? I believe that the
code is ok.

Can someone else probably test some other compilers and report the results?

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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              ]

Matthias Meixner wrote:
>
>
> struct Z { Z(){} };
>
> struct B {
>    Z x;
>
>    operator Z &() { puts("ba"); return x; }
>    operator const Z &() { puts("bb"); return x; }
>    operator const Z &() const { puts("bc"); return x; }
> };
>
> main()
> {
>    B b;
>    const B cb;
>    Z &b1=b;
>    const Z &b2=b;
>    const Z &b3=cb;
>
> }
>
> This code was compiled using 4 different compilers. Two of which compile
> without problems, whereas the other two claim that the "conversion from
> `B' to `const Z &' is ambiguous".
>
> The compilers tested were:
>
> gcc:                        error
> comeau C++ (WWW compiler):  error
> Sun Workshop PRO 5.0:       ok
> Borland C++:                ok
>
> So which compilers are right and which have an error? I believe that the
> code is ok.

No, the code is not ok. Both the const and non-const "const Z&"
operators are viable in the statement:

  const Z& b2 = b;

since b is not a const object. So, gcc amd comeau got it right.

--
Biju Thomas

---
[ 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 <3909C77B.9F5B427C@attglobal.net>,
  b.thomas@attglobal.net wrote:
> Matthias Meixner wrote:
> > struct Z { Z(){} };
> >
> > struct B {
> >    Z x;
> >
> >    operator Z &() { puts("ba"); return x; }
> >    operator const Z &() { puts("bb"); return x; }
> >    operator const Z &() const { puts("bc"); return x; }
> > };
> >
> > main()
> > {
> >    B b;
> >    const B cb;
> >    Z &b1=b;
> >    const Z &b2=b;
> >    const Z &b3=cb;
[snip]
> > So which compilers are right and which have an error? I believe that
the
> > code is ok.
>
> No, the code is not ok. Both the const and non-const "const Z&"
> operators are viable in the statement:
>
>   const Z& b2 = b;
I agree that the code is not OK, but if I read the Standard correctly,
the contention is between 'operator Z&();' and 'operator const Z&();',
not between 'operator const Z&();' and 'operator const Z&() const;'

OK, lemme see if I follow the rules right on this (MSVC got it wrong
too, by the way).

According to (13.3.1.1.1 /2) the candidate functions are:

a)  B::operator Z &();
b)  B::operator const Z &();
c)  B::operator const Z &() const;

So now we determine the viable functions according to 13.3.2

All three operators meet the first criteria in para 2 - same number of
parameters.  They each take exactly one parameter, the implied 'this'.

According to Table 9 in 13.3.3.1.1 all three functions have a ranking of
Exact Match.  The first two [a and b] are Identity, the third [c] is
Qualification Adjustment.

Now, to rank the conversion sequences, by 13.3.3.2

The implied parameter to (a) and (b) is 'B &', and to (c) is 'const B&'.
This means that (c) is a worse conversion sequence than (a) and (b)
because 'const B&' is more cv-qualified than 'B&' according to the
fourth point under paragraph 3, which begins "S1 and S2 are reference
bindings (8.5.3) and the types to which the references refer are the
same..."

Since functions (a) and (b) are indistinguishable in their implicit
conversion sequences, the program is ill-formed.

Did I get it right?

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

| > struct Z { Z(){} };
| >
| > struct B {
| >    Z x;
| >
| >    operator Z &() { puts("ba"); return x; }
| >    operator const Z &() { puts("bb"); return x; }
| >    operator const Z &() const { puts("bc"); return x; }
| > };
| >
| > main()
| > {
| >    B b;
| >    const B cb;
| >    Z &b1=b;
| >    const Z &b2=b;
| >    const Z &b3=cb;
| >
| > }
| >
| > This code was compiled using 4 different compilers. Two of which compile
| > without problems, whereas the other two claim that the "conversion from
| > `B' to `const Z &' is ambiguous".
| >
| > The compilers tested were:
| >
| > gcc:                        error
| > comeau C++ (WWW compiler):  error
| > Sun Workshop PRO 5.0:       ok
| > Borland C++:                ok
| >
| > So which compilers are right and which have an error? I believe that the
| > code is ok.
|
| No, the code is not ok. Both the const and non-const "const Z&"
| operators are viable in the statement:
|
|   const Z& b2 = b;
|
| since b is not a const object. So, gcc amd comeau got it right.

This is wrong. Given the following declaration:
class X {
public:
    int foo() { return 12; }
    int foo() const { return 12; }
};

the following is perfectly valid:

int main() {
    X x;
    x.foo();
}

The "const" function is called if and only if the object it is called upon
is const itself. Otherwise, the non-const variant is prefered. The compiler
may not call this code ambiguous at all.

Regards,

Christian Parpart


---
[ 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              ]

Christian Parpart wrote:
>
> | No, the code is not ok. Both the const and non-const "const Z&"
> | operators are viable in the statement:
> |
> |   const Z& b2 = b;
> |
> | since b is not a const object. So, gcc amd comeau got it right.
>
> This is wrong.
[...]
>
> The "const" function is called if and only if the object it is called upon
> is const itself. Otherwise, the non-const variant is prefered. The compiler
> may not call this code ambiguous at all.

Mea culpa. Still, the original code is invalid. The conflict is between
the "Z&()" and "const Z&()" operators. (See the post by Jim Hyslop.
Thanks Jim!)

--
Biju Thomas

---
[ 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              ]

Biju Thomas <b.thomas@attglobal.net> writes:

|>  Christian Parpart wrote:

|>  > | No, the code is not ok. Both the const and non-const "const Z&"
|>  > | operators are viable in the statement:

|>  > |   const Z& b2 =3D b;

|>  > | since b is not a const object. So, gcc amd comeau got it right.

|>  > This is wrong.=20
|>  [...]

|>  > The "const" function is called if and only if the object it is
|>  > called upon is const itself. Otherwise, the non-const variant is
|>  > prefered. The compiler may not call this code ambiguous at all.

|>  Mea culpa. Still, the original code is invalid. The conflict is betwe=
en
|>  the "Z&()" and "const Z&()" operators. (See the post by Jim Hyslop.
|>  Thanks Jim!)

Except perhaps, for 13.3.3: the third point of the second bulleted list
states: "the context is an initialization by user-defined conversion and
the standard conversion sequence from the return type of F1 to the
destination type (i.e., the type of the entity being initialized) is a
better conversion sequence than the standard conversion sequence from
the return type of F2 to the destination type."  This is one of the rare
cases where the result type enters into overload resolution.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

rodb@bridge.com (Rod Burman) writes:

>I have found that two compilers I commonly use dis-agree on the following code
>
>//const\
>int a;
>
>(This is the minimal version the real problem I had was much longer)
>
>Dec C++ (VAX/VMS) translates this to: "" i.e. it concatenates the lines
> then eliminates comments
>Borland (80*86/MS-Windows) translates to "int a;" i.e. eliminates //
> comments and then (presumably) concatenates lines

DEC C++ is right, Borland is wrong.

> Now I know ISO C has a set of compiltation phases that goes
>something like:
>
> replace trigraphs
> concatenate lines
> replace multiple white space (including \n and comments) with ' '
> rest of pre-processing
> rest of real compiler processing

The C++ committee's working paper specifies the same order as you listed.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

I have found that two compilers I commonly use dis-agree on the following code

//const\
int a;

(This is the minimal version the real problem I had was much longer)

Dec C++ (VAX/VMS) translates this to: "" i.e. it concatenates the lines
 then eliminates comments
Borland (80*86/MS-Windows) translates to "int a;" i.e. eliminates //
 comments and then (presumably) concatenates lines

 Now I know ISO C has a set of compiltation phases that goes
something like:

 replace trigraphs
 concatenate lines
 replace multiple white space (including \n and comments) with ' '
 rest of pre-processing
 rest of real compiler processing

 But of course // is C++ only so I can't rely on the C sequence,
so who is right according to the draft ISO C++ spec? Or should I just
phone both vendors? Or just run it through C-Front for a third opinion?
 Thanks for any comments
  Rod Burman rodb@bridge.com

In article g2@news.bridge.com, rodb@bridge.com (Rod Burman) writes:
>I have found that two compilers I commonly use dis-agree on the following code
>
>//const\
>int a;
>
>(This is the minimal version the real problem I had was much longer)
>
>Dec C++ (VAX/VMS) translates this to: "" i.e. it concatenates the lines
> then eliminates comments
>Borland (80*86/MS-Windows) translates to "int a;" i.e. eliminates //
> comments and then (presumably) concatenates lines

C++ is supposed to correspond to C in translation phases. So the lines
are concatenated, and then comments removed. Your example should result in
everything being thrown away.

---
Steve Clamage, stephen.clamage@eng.sun.com