In article <7rl504$7v1$1@nnrp1.deja.com>,
  James.Kanze@dresdner-bank.com wrote:
> In article <7rdp2p$7a8$1@nnrp1.deja.com>,
>   wmm@fastdial.net wrote:
> >
> > In article <7rbbuh$il8$1@nnrp1.deja.com>,
> >   James.Kanze@dresdner-bank.com wrote:
> > > In article <0a19a4842050799CPIMSSMTPE01@msn.com>,
> > >   "Gene Bushuyev" <gbush@my-deja.com> wrote:
> > > > <mleonov@my-deja.com> wrote in message
> > > news:7qvlel$3l8$1@nnrp1.deja.com...
> > > > >
> > > > > Suppose we have:
> > > > > class A
> > > > > {
> > > > > /* ... */
> > > > > public:
> > > > > operator char *()
> > > > > { /* ... */ }
> > > > > operator const char *() const
> > > > > { /* ... */ }
> > > > > };
> > > > > which of the 2 conversion operators should be
> > > > > called for the following line:
> > > > > A a; const char * s = a;
> > >
> > > > It calls operator char *().
> > >
> > > No.  It calls operator const char*().
> >
> > No, it calls operator char*().  See below.
>
> > > The context is that of "a user defined conversion for copy
> > > initialization" (see 13.3./2).  Overload resolution starts by
> > > creating a list of candidate functions.  There are two possible
> > > types of candidate functions, converting constructors (none for
> > > const char*), and conversion operators in the initializing class.
> > > For a conversion operator to be a candidate function, it must
yield
> > > a type whose cv-unqualified type is the same as the target type,
or
> > > is a class derived from the target type.  Here, the target type is
> > > const char* -- we can ignore the derived class issue -- so the
> > > conversion function must yield one of the four following types:
char
> > > const*, char const* volatile, char const* const, or char const*
> > > const volatile.  In fact, there is only one conversion operator
> > > yielding any of these types, operator char const*().  So the list
of
> > > candidate functions contains exactly this one function.
>
> > > I'll skim over the rest: the function is viable (13.3.2), and
since
> > > it is the only function in the list, we don't have to look at all
of
> > > the ordering criteria to determine that it is the best.
>
> > This is covered in 13.3.1.5, "Initialization by conversion
function."
> > (I think you were looking in 13.3.1.4, "Copy-initialization of class
> > by user-defined conversion."  That doesn't apply because "s" isn't a
> > class.)
>
> I was.
>
> > The candidate functions are all those conversion functions of "A"
that
> > yield the target type, "const char*", or a type that can be
converted
> > to the target type by a standard conversion sequence.  "char*" can
be
> > converted to "const char*" by a standard conversion sequence, so
both
> > of the conversion functions are candidates.  The argument list for
> > overload resolution has one argument, which is the initializer
> > expression "a", of type "A".
>
> > Now we go to 13.3.2.  Both conversion functions are viable: A is an
> > an "exact match (identity)" for "A::operator char*()" and an "exact
> > match (qualification adjustment)" for "A::operator const char*()
> const."
>
> I still don't understand this.  The final goal is to convert A to a
char
> const*.  The target type is thus char const*.  Surely it is the
function
> A::operator char const*() that is the exact match, and A::operator
> char*() which has the qualification adjustment.

13.3.1.5p2: "The argument list has one argument, which is the
initializer expression. [Note: this argument will be compared
against the implicit object parameter of the conversion function.]"

The implicit object parameter of a member function is described in
13.3.1p4: "For non-static member functions, the type of the implicit
object parameter is 'reference to cv X' where X is the class of
which the function is a member and cv is the cv-qualification on
the member function declaration."

That means that for "A::operator char*()" the implicit object
parameter is "A&"; for "A::operator const char*() const", it is
"const A&".  In the conversion expression, the initializer
expression is "a", which has type "A".  It is therefore a better
match for the implicit object parameter of "A::operator char*()",
according to 13.3.3.2p3, bullet 1, sub-bullet 1.

And, according to 13.3.3p1, the argument match (first bullet in the
list in the second list in the paragraph) takes precedence over the
return type match (fourth bullet).

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> The types "const char*" and char const*" are the same type.

Sure.

But the original confusion remains: is the attempted conversion
well-formed, and, if yes, which of the operators is called?

So far, I have read good arguments for both operators.

[It was me who (in another newsgroup) suggested to the original poster to
ask his question here, so please don't let me down :-)]




[ 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 <7rdp2p$7a8$1@nnrp1.deja.com>,
  wmm@fastdial.net wrote:
>
> In article <7rbbuh$il8$1@nnrp1.deja.com>,
>   James.Kanze@dresdner-bank.com wrote:
> > In article <0a19a4842050799CPIMSSMTPE01@msn.com>,
> >   "Gene Bushuyev" <gbush@my-deja.com> wrote:
> > > <mleonov@my-deja.com> wrote in message
> > news:7qvlel$3l8$1@nnrp1.deja.com...
> > > >
> > > > Suppose we have:
> > > > class A
> > > > {
> > > > /* ... */
> > > > public:
> > > > operator char *()
> > > > { /* ... */ }
> > > > operator const char *() const
> > > > { /* ... */ }
> > > > };
> > > > which of the 2 conversion operators should be
> > > > called for the following line:
> > > > A a; const char * s = a;
> >
> > > It calls operator char *().
> >
> > No.  It calls operator const char*().
>
> No, it calls operator char*().  See below.

> > The context is that of "a user defined conversion for copy
> > initialization" (see 13.3./2).  Overload resolution starts by
> > creating a list of candidate functions.  There are two possible
> > types of candidate functions, converting constructors (none for
> > const char*), and conversion operators in the initializing class.
> > For a conversion operator to be a candidate function, it must yield
> > a type whose cv-unqualified type is the same as the target type, or
> > is a class derived from the target type.  Here, the target type is
> > const char* -- we can ignore the derived class issue -- so the
> > conversion function must yield one of the four following types: char
> > const*, char const* volatile, char const* const, or char const*
> > const volatile.  In fact, there is only one conversion operator
> > yielding any of these types, operator char const*().  So the list of
> > candidate functions contains exactly this one function.

> > I'll skim over the rest: the function is viable (13.3.2), and since
> > it is the only function in the list, we don't have to look at all of
> > the ordering criteria to determine that it is the best.

> This is covered in 13.3.1.5, "Initialization by conversion function."
> (I think you were looking in 13.3.1.4, "Copy-initialization of class
> by user-defined conversion."  That doesn't apply because "s" isn't a
> class.)

I was.

> The candidate functions are all those conversion functions of "A" that
> yield the target type, "const char*", or a type that can be converted
> to the target type by a standard conversion sequence.  "char*" can be
> converted to "const char*" by a standard conversion sequence, so both
> of the conversion functions are candidates.  The argument list for
> overload resolution has one argument, which is the initializer
> expression "a", of type "A".

> Now we go to 13.3.2.  Both conversion functions are viable: A is an
> an "exact match (identity)" for "A::operator char*()" and an "exact
> match (qualification adjustment)" for "A::operator const char*()
const."

I still don't understand this.  The final goal is to convert A to a char
const*.  The target type is thus char const*.  Surely it is the function
A::operator char const*() that is the exact match, and A::operator
char*() which has the qualification adjustment.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37DB947C.FDEF110C@glue.ch>,
  Thomas Maeder <maeder@glue.ch> wrote:
> But the original confusion remains: is the attempted conversion
> well-formed, and, if yes, which of the operators is called?
>
> So far, I have read good arguments for both operators.
>
> [It was me who (in another newsgroup) suggested to the original poster
to
> ask his question here, so please don't let me down :-)]

What will you accept as resolving "the original confusion?"

Overload resolution is hairy, probably the second most difficult
part of the language (behind some of the template features).  The
Standard does give a definitive answer to this question, however
confusing it is, and it's been given a couple of times, both in this
thread and the one a few days ago: it's well-formed, and it calls
operator char*(), not operator const char*() const, because argument
matching (on the "this" parameter) takes precedence over return type
matching in selecting conversion functions.

In my posting (which no one has challenged yet) I cited the exact
path through clause 13 that leads to this conclusion.  In the other
thread, Steve Adamczyk (who _wrote_ most of that specification)
also said that operator char*() is selected.

What more do you want?
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg wrote:
>
> The reason for all this, of course, is consistency. Putting const last
> means it always modifies (er... makes const :-) what is on the left of it.
>
>     int                 int
>     int const           int that is const
>     int* const          int* that is const
>     int const* const    int that is const* that is const

I always preferred the 'reading backwards' method, to get

    int                 int
    int const           const int
    int* const          const pointer to int
    int const* const    const pointer to const int

Then, when you get a total nightmare like

    int const * * const * const *

You know it's a pointer to a const pointer to a const pointer to a
pointer to a const int.

Which makes it so much clearer :)

Adam

--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?

----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.
---
[ 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 <7rbbuh$il8$1@nnrp1.deja.com>,
  James.Kanze@dresdner-bank.com wrote:
> In article <0a19a4842050799CPIMSSMTPE01@msn.com>,
>   "Gene Bushuyev" <gbush@my-deja.com> wrote:
> > <mleonov@my-deja.com> wrote in message
> news:7qvlel$3l8$1@nnrp1.deja.com...
> > >
> > > Suppose we have:
> > > class A
> > > {
> > > /* ... */
> > > public:
> > > operator char *()
> > > { /* ... */ }
> > > operator const char *() const
> > > { /* ... */ }
> > > };
> > > which of the 2 conversion operators should be
> > > called for the following line:
> > > A a; const char * s = a;
>
> > It calls operator char *().
>
> No.  It calls operator const char*().

No, it calls operator char*().  See below.

> The context is that of "a user defined conversion for copy
> initialization" (see 13.3./2).  Overload resolution starts by creating a
> list of candidate functions.  There are two possible types of candidate
> functions, converting constructors (none for const char*), and
> conversion operators in the initializing class.  For a conversion
> operator to be a candidate function, it must yield a type whose
> cv-unqualified type is the same as the target type, or is a class
> derived from the target type.  Here, the target type is const char* --
> we can ignore the derived class issue -- so the conversion function must
> yield one of the four following types: char const*, char const*
> volatile, char const* const, or char const* const volatile.  In fact,
> there is only one conversion operator yielding any of these types,
> operator char const*().  So the list of candidate functions contains
> exactly this one function.
>
> I'll skim over the rest: the function is viable (13.3.2), and since it
> is the only function in the list, we don't have to look at all of the
> ordering criteria to determine that it is the best.

This is covered in 13.3.1.5, "Initialization by conversion function."
(I think you were looking in 13.3.1.4, "Copy-initialization of class
by user-defined conversion."  That doesn't apply because "s" isn't a
class.)

The candidate functions are all those conversion functions of "A" that
yield the target type, "const char*", or a type that can be converted
to the target type by a standard conversion sequence.  "char*" can be
converted to "const char*" by a standard conversion sequence, so both
of the conversion functions are candidates.  The argument list for
overload resolution has one argument, which is the initializer
expression "a", of type "A".

Now we go to 13.3.2.  Both conversion functions are viable: A is an
an "exact match (identity)" for "A::operator char*()" and an "exact
match (qualification adjustment)" for "A::operator const char*() const."

Next we go to 13.3.3.2 to compare the argument conversion sequences.
Although both are "exact matches," an "identity" conversion is a
subsequence of a "qualification adjustment," so the initializer "a" is
a better match for "A::operator char*()" than for
"A::operator const char*() const."

Finally we go to 13.3.3 to determine the best viable function.  Since
"A::operator char*()" is a better match on the single argument than
"A::operator const char*() const," it is selected as the result.  (The
fact that the result type of "A::operator const char*() const" is a
better match for the target type, "const char*", would only apply if
the conversion functions were indistinguishable in every other way;
it's the last bullet in 13.3.3p1.)
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com wrote:

>
> > It calls operator char *().
>
> No.  It calls operator const char*().
                ^^^^^^^^^^^^^^^^^^^^^^^
                ^^^^^^^^^^^^^^^^^^^^^^^
>
> The context is that of "a user defined conversion for copy
> initialization" (see 13.3./2).  Overload resolution starts by creating a
> list of candidate functions.  There are two possible types of candidate
> functions, converting constructors (none for const char*), and
> conversion operators in the initializing class.  For a conversion
> operator to be a candidate function, it must yield a type whose
> cv-unqualified type is the same as the target type, or is a class
> derived from the target type.  Here, the target type is const char* --
> we can ignore the derived class issue -- so the conversion function must
> yield one of the four following types: char const*, char const*
> volatile, char const* const, or char const* const volatile.  In fact,
> there is only one conversion operator yielding any of these types,
> operator char const*().  So the list of candidate functions contains
  ^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^^^^^^^^^^^^^^

Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
Or did another one just, fly, over me ?

--

       Regards,
  Bill T.


=================================================
If it was working before, and is not working now;
What did you change ?
=================================================



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

Bill Thompson wrote:
>
> James.Kanze@dresdner-bank.com wrote:
...
> > No.  It calls operator const char*().
>                 ^^^^^^^^^^^^^^^^^^^^^^^
>                 ^^^^^^^^^^^^^^^^^^^^^^^
...
> > operator char const*(). ...
>   ^^^^^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^
>
> Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
> Or did another one just, fly, over me ?

No - 'const char *' and 'char const *' both mean the same thing: a
pointer to a const char. You only get a different type by moving the
'const' across the '*': 'char *const' means that the pointer value
itself is const.
---
[ 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 <37DA169A.A76ACCC9@ibm.net>, Bill Thompson <bill.t@ibm.net>
writes
>Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
>Or did another one just, fly, over me ?
operator const char *
and
operator char const *

are identical.  It makes no difference which side of the type you place
the cv qualification, even worse, I believe the following are all
equivalent:

const unsigned short int
unsigned const short int
unsigned short const int
unsigned short int const

and I think you can play games with the positioning unsigned and short.




Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Thompson <bill.t@ibm.net> writes:

>James.Kanze@dresdner-bank.com wrote:
>
>> > It calls operator char *().
>>
>> No.  It calls operator const char*().
>                ^^^^^^^^^^^^^^^^^^^^^^^
>> ...
>>
>> there is only one conversion operator yielding any of these types,
>> operator char const*().  ...
>  ^^^^^^^^^^^^^^^^^^^^^^^

>Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
>Or did another one just, fly, over me ?

I guess another one flew over you. :-)

The types "const char*" and char const*" are the same type.

Maybe you are thinking of the difference between
"const char*" and "char* const".

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37DAA507.5446F666@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:

> Bill Thompson wrote:
> >
> > James.Kanze@dresdner-bank.com wrote:
> ...
> > > No.  It calls operator const char*().
> >                 ^^^^^^^^^^^^^^^^^^^^^^^
> >                 ^^^^^^^^^^^^^^^^^^^^^^^
> ...
> > > operator char const*(). ...
> >   ^^^^^^^^^^^^^^^^^^^^^^^
> >   ^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
> > Or did another one just, fly, over me ?
>
> No - 'const char *' and 'char const *' both mean the same thing: a
> pointer to a const char. You only get a different type by moving the
> 'const' across the '*': 'char *const' means that the pointer value
> itself is const.

The reason for all this, of course, is consistency. Putting const last
means it always modifies (er... makes const :-) what is on the left of it.

    int                 int
    int const           int that is const
    int* const          int* that is const
    int const* const    int that is const* that is const

Very regular rules.
---
[ 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 <9JxKenAZtq23EwSs@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <37DA169A.A76ACCC9@ibm.net>, Bill Thompson <bill.t@ibm.net>
> writes
> >Ain't there a difference ?  Ya switched mid paragraph; (shzoom)
> >Or did another one just, fly, over me ?
> operator const char *
> and
> operator char const *

> are identical.  It makes no difference which side of the type you
> place the cv qualification, even worse, I believe the following are
> all equivalent:

> const unsigned short int
> unsigned const short int
> unsigned short const int
> unsigned short int const

> and I think you can play games with the positioning unsigned and
> short.

You can.  In this case, there are 24 different orderings, all legal.

The same thing applies to static, etc. So if you have a:
    static unsigned short int const
it is exactly the same as:
    const int short static unsigned
or any of the 118 other possible orderings.

This doesn't mean that you should try and use all of the possible
orderings in a single program.  I generally use: storage specifier,
signedness modifier, length modifier, basic type, cv-qualifiers.  My
impression is that this is more or less the standard, about the only
variation I see is that there are still a number of people who put the
cv-qualifier before the signedness modifier.  Also, most people allow
dropping some of the elements -- the basic type, for example, if a
signedness or length modifier is given.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0a19a4842050799CPIMSSMTPE01@msn.com>,
  "Gene Bushuyev" <gbush@my-deja.com> wrote:
> <mleonov@my-deja.com> wrote in message
news:7qvlel$3l8$1@nnrp1.deja.com...
> >
> > Suppose we have:
> > class A
> > {
> > /* ... */
> > public:
> > operator char *()
> > { /* ... */ }
> > operator const char *() const
> > { /* ... */ }
> > };
> > which of the 2 conversion operators should be
> > called for the following line:
> > A a; const char * s = a;

> It calls operator char *().

No.  It calls operator const char*().

The context is that of "a user defined conversion for copy
initialization" (see 13.3./2).  Overload resolution starts by creating a
list of candidate functions.  There are two possible types of candidate
functions, converting constructors (none for const char*), and
conversion operators in the initializing class.  For a conversion
operator to be a candidate function, it must yield a type whose
cv-unqualified type is the same as the target type, or is a class
derived from the target type.  Here, the target type is const char* --
we can ignore the derived class issue -- so the conversion function must
yield one of the four following types: char const*, char const*
volatile, char const* const, or char const* const volatile.  In fact,
there is only one conversion operator yielding any of these types,
operator char const*().  So the list of candidate functions contains
exactly this one function.

I'll skim over the rest: the function is viable (13.3.2), and since it
is the only function in the list, we don't have to look at all of the
ordering criteria to determine that it is the best.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Suppose we have:
class A
{
/* ... */
public:
operator char *()
{ /* ... */ }
operator const char *() const
{ /* ... */ }
};
which of the 2 conversion operators should be
called for the following line:
A a; const char * s = a;



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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 6 Sep 1999 14:32:31 GMT, mleonov@my-deja.com <mleonov@my-deja.com> wrote:

>Suppose we have:
>class A
>{
>/* ... */
>public:
>operator char *()
>{ /* ... */ }
>operator const char *() const
>{ /* ... */ }
>};

>which of the 2 conversion operators should be
>called for the following line:
>A a; const char * s = a;

As operator conversions are like overloading by return value, the
compiler selects "operator const char *() const".  At least that's
what I think happens.

--
--------------
siemel b naran
--------------


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

<mleonov@my-deja.com> wrote in message news:7qvlel$3l8$1@nnrp1.deja.com...
>
> Suppose we have:
> class A
> {
> /* ... */
> public:
> operator char *()
> { /* ... */ }
> operator const char *() const
> { /* ... */ }
> };
> which of the 2 conversion operators should be
> called for the following line:
> A a; const char * s = a;

It calls operator char *().

Why don't you go a few posts up and see exactly this question discussed
under the title "overload resolution question."

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