Valentin Bonnard wrote:
>
> Brian Glendenning wrote:
>  > We have been using a Boolean enumeration in our project for several
>  > years now, and are thinking of moving to real "bool" since we figure
>  > it should be safe to do so.
>  >
>  > We have run into an overloading situation that we consider to be
>  > surprising. We have a String class that has a constructor that takes a
>  > const char*. We are surprised when we have functions overloaded on
>  > String and bool, that a const char* argument calls the bool version,
>  > not the String version.
[...]
> User defined conversions (for example const char* -> String) are never
> prefered against other types of conversions, so the both statements
> call f(bool).

Is it really true? I remember that user-defined conversions can be
applied in a conversion sequence but only once. Here we have the
situation.  What says std?


13.3.3.2

"2 When comparing the basic forms of implicit  conversion  sequences
(as defined in _over.best.ics_)

  --a  standard conversion sequence (_over.ics.scs_) is a better conver-
    sion sequence than a user-defined conversion sequence or an ellipsis
    conversion sequence, and

  --a  user-defined  conversion  sequence  (_over.ics.user_) is a better
    conversion   sequence   than   an   ellipsis   conversion   sequence
    (_over.ics.ellipsis_)."

So might be in this compiler, for less problems with older versions of
software where pointer was treated as a bool (NULL or not), they
introduced their own "standard" conversion from pointer to bool...



Stanislaw Bochnak

---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stanislaw Bochnak wrote:
>
> Valentin Bonnard wrote:
> >
> > Brian Glendenning wrote:

> >  > We have run into an overloading situation that we consider to be
> >  > surprising. We have a String class that has a constructor that takes a
> >  > const char*. We are surprised when we have functions overloaded on
> >  > String and bool, that a const char* argument calls the bool version,
> >  > not the String version.
> [...]
> > User defined conversions (for example const char* -> String) are never
> > prefered against other types of conversions, so the both statements
> > call f(bool).
>
> Is it really true?

Yes. Ok, I assumed that no one care about vararg functions.

> I remember that user-defined conversions can be
> applied in a conversion sequence but only once.

Correct, but doesn't apply here as there is only one
user defined conversion.

> Here we have the
> situation.  What says std?
>
> 13.3.3.2
>
> "2 When comparing the basic forms of implicit  conversion  sequences
> (as defined in _over.best.ics_)

[...]

> So might be in this compiler, for less problems with older versions of
> software where pointer was treated as a bool (NULL or not), they
> introduced their own "standard" conversion from pointer to bool...

The implicit comversion from pointer to bool is really in the
standard. I don't know why you quote "standard".

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

We have been using a Boolean enumeration in our project for several
years now, and are thinking of moving to real "bool" since we figure
it should be safe to do so.

We have run into an overloading situation that we consider to be
surprising. We have a String class that has a constructor that takes a
const char*. We are surprised when we have functions overloaded on
String and bool, that a const char* argument calls the bool version,
not the String version. Probably an example would help:

#include <iostream.h>

class String
{
public:
  String(const char*) {}
};

void f(const String&) { cout << "string\n"; }
void f(bool)         { cout << "bool\n"; }

int main()
{
  const char carr[] = "abcd";
  const char *cptr = &carr[0];

  f(cptr);   // bool!!
  f(carr);   // string

  return 0;
}

We find it somewhat surprising that bool is preferred to string for
the first call, and even more surprising that the same function isn't
called both times. Could somebody explain this? Thanks.

[This is with g++ 2.7.2, but we believe we have seen the same thing
with a compiler based on a recent EDG front-end.]

Brian
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

With the following:

#include <iostream.h>
// added to work with this program
typedef enum {FALSE, TRUE} bool;
class String
{
public:
  String(const char*) {}
};
void f(const String&) { cout << "string\n"; }
void f(bool)  { cout << "bool\n"; }
int main()
{
  const char carr[] = "abcd";
  const char *cptr = &carr[0];
  f(cptr);   // bool!!
  f(carr);    // string

  return 0;
}

I got the output:
string
string

This was done with Microsoft cl 10 (32bit) under WinNT4.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Brian Glendenning wrote:
 > We have been using a Boolean enumeration in our project for several
 > years now, and are thinking of moving to real "bool" since we figure
 > it should be safe to do so.
 >
 > We have run into an overloading situation that we consider to be
 > surprising. We have a String class that has a constructor that takes a
 > const char*. We are surprised when we have functions overloaded on
 > String and bool, that a const char* argument calls the bool version,
 > not the String version. Probably an example would help:
 >
 > #include <iostream.h>
 >
 > class String
 > {
 > public:
 >   String(const char*) {}
 > };
 >
 > void f(const String&) { cout << "string\n"; }
 > void f(bool)         { cout << "bool\n"; }
 >
 > int main()
 > {
 >   const char carr[] = "abcd";
 >   const char *cptr = &carr[0];
 >
 >   f(cptr);   // bool!!
 >   f(carr);   // string
 >
 >   return 0;
 > }
 >
 > We find it somewhat surprising that bool is preferred to string for
 > the first call, and even more surprising that the same function isn't
 > called both times. Could somebody explain this? Thanks.

User defined conversions (for example const char* -> String) are never
prefered against other types of conversions, so the both statements
call f(bool).

OTOH if you use enum { ... } BOOL; then f(BOOL) won't even be
considered, so the previous behaviour was correct.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]