Circumventing explicit constructors

[D.J. Stachniak]

Hi,

I have a question about explicit constructors and the C++ standard.
Forgive me for my laziness in not pouring over the spec myself, but I
thought I'd ask first and read later. I have a class/app like so:

#include <string>
#include <iostream>

class UTF8string
{
public:
UTF8string() { }

explicit UTF8string(const char* charArray) : m_str(charArray) { }

UTF8string(const std::string& str) : m_str(str) { }

const char* c_str() { return m_str.c_str(); }

private:
std::string m_str;
};

int main(int argc, char* argv[])
{
UTF8string str = "Hello, world!";

std::cout << "str.c_str() = " << str.c_str() << std::endl;

return 0;
}

I've obviously left out a lot of irrelevant details, but what I'd like
to know is this: under VC++ 7.1 this compiles and under GCC 3.4.2 it
doesn't. GCC complains as I would expect that it can't convert "Hello,
world!" to a UTF8string object because the const char* ctor is
explicit. VC++, however, silently converts my "Hello, world!" literal
to a std::string and invokes UTF8string's const std::string& ctor.

I don't necessarily have a problem with making my const std::string&
ctor explicit as well, but I'd like to know the rules for silent
conversions like this. Who's in the right - GCC or VC++? And what are
the rules regarding the number of levels a compiler can go to find a
match?

Thanks,
D.J. Stachniak

[Valentin Samko]

D.J. Stachniak wrote:

class UTF8string
{
public:
UTF8string() { }
explicit UTF8string(const char* charArray) : m_str(charArray) { }
UTF8string(const std::string& str) : m_str(str) { } I've obviously left out a lot of irrelevant details, but what I'd like
to know is this: under VC++ 7.1 this compiles and under GCC 3.4.2 it
doesn't. GCC complains as I would expect that it can't convert "Hello,
world!" to a UTF8string object because the const char* ctor is
explicit. VC++, however, silently converts my "Hello, world!" literal
to a std::string and invokes UTF8string's const std::string& ctor.
UTF8string str = "Hello, world!";

VC7.1 is incorrect here. The rhs, i.e. const char* must be converted to the type of the
lhs first, see 8.5/14. VC7.1 is known to have a problem with this type of initialisation
where it does not follow the standard, see the thread "conversion constructor called twice
- why?".

--

Valentin Samko - http://www.valentinsamko.com

[Kaz Kylheku]

D.J. Stachniak wrote:

I don't necessarily have a problem with making my const std::string&
ctor explicit as well, but I'd like to know the rules for silent
conversions like this. Who's in the right - GCC or VC++? And what are
the rules regarding the number of levels a compiler can go to find a
match?

Like you, I'm too lazy to go into the spec! But, haha! Permit me the
following piece of speculation, anyway.

It must be the case that, under overload resolution, constructors are
considered without regard to their being declared explicit or not. The
candidate is chosen, and if it is explicit, a diagnostic is required.

In your program, the const char * constructor is the better match,
because it doesn't require a user-defined conversion. So it must be
chosen, and then a diagnostic is issued because the constructor is
explicit.

This is the correct design, rather than eliminating all the explicit
constructors from consideration as if they did not exist, and
considering only the remaining functions as overload candidates.

This design allows the explicit feature to be a superior diagnostic
tool. By turning on the explicit attribute on a constructor, you can
detect that it's being selected, without disturbing the logic which
makes that selection. This is analogous to access specifiers, which
don't alter any visibility rules, but merely flag certain accesses as
disallowed.

[Neelesh Bodas]

Kaz Kylheku wrote:

In your program, the const char * constructor is the better match,
because it doesn't require a user-defined conversion. So it must be
chosen, and then a diagnostic is issued because the constructor is
explicit.

IMHO, const char* constructor is the _only_ possible match. The other
constructor simply cannot match, since it will require _two_ user
defined conversions : const char[] --> std::string --> UTF8string

Please correct me if I am wrong.

[Sumit Rajan]

"D.J. Stachniak" <dj*********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

I don't necessarily have a problem with making my const std::string&
ctor explicit as well, but I'd like to know the rules for silent
conversions like this. Who's in the right - GCC or VC++? And what are
the rules regarding the number of levels a compiler can go to find a
match?

As the others have already mentioned, g++ is "right" in this case.

However, you will find that VC++ (7.1) too emits a compiler error in this
case when you try to compile the code with the /Za switch (which disables
extensions).

Regards,
Sumit.
--
Sumit Rajan <su****@msdc.hcltech.com>

[Kaz Kylheku]

Neelesh Bodas wrote:

Kaz Kylheku wrote:

In your program, the const char * constructor is the better match,
because it doesn't require a user-defined conversion. So it must be
chosen, and then a diagnostic is issued because the constructor is
explicit.

IMHO, const char* constructor is the _only_ possible match. The other
constructor simply cannot match, since it will require _two_ user
defined conversions : const char[] --> std::string --> UTF8string

Please correct me if I am wrong.

We are talking about the line:

UTF8string str = "Hello, world!";

In calling the const std::string & constructor, there is only one
conversion involved.

There is a second conversion going on, from std::string to UTF8String
object. But the constructor call /is/ that conversion. This second
conversion is not part of the conversion chain that must be done in
order to produce the argument for the constructor call; it's done by
that call.

[Neelesh Bodas]

Kaz Kylheku wrote:

We are talking about the line:

UTF8string str = "Hello, world!";

In calling the const std::string & constructor, there is only one
conversion involved.

There is a second conversion going on, from std::string to UTF8String
object. But the constructor call /is/ that conversion. This second
conversion is not part of the conversion chain that must be done in
order to produce the argument for the constructor call; it's done by
that call.

Hello Kaz,
Thanks for the explanation. Actually I am still a bit confused.
Suppose I comment out all other other constructors but retain this one
-

UTF8string ( const std::string& str);

Now (according to what I understand from your explanation), this
constructor should be a legal candidate for the expression :

UTF8string str = "Hello, world"; // The LHS must get constructed from
the RHS.

Howvever, this code fails to compile (g++ 3.4.2).

Further, If I make one of the two conversions explicit, then the code
works :

UTF8string str = std::String("Hello, world");
// OK, const char[] --> std:: string called explicitly, other
conversion is implicit

UTF8string str = UTFString("Hello, world" );
// OK, std::string --> UTF8string called explicitly, other conversion
is implicit

This is precisely the reason why I believed the two-conversion issue
(and wrote the previous reply)

So basically, IMHO, when we say
X foo = bar, there _is_ a conversion from bar to some temporary of type
X, and then a call to CC to construct a foo. Of course the compilers
might optimize the CC call, but the underlying type conversion does
take place.

Of course I might be wrong and missing out some sublte points here.
Could you please comment on this?

[D.J. Stachniak]

I just found a switch for the VC compiler (/Za) that forces compliance
with standard C++. With this flag set my code above no longer compiles
under VC, so clearly GCC is correct. Thanks for everyone's help.

[Kaz Kylheku]

Neelesh Bodas wrote:

Hello Kaz,
Thanks for the explanation. Actually I am still a bit confused.
Suppose I comment out all other other constructors but retain this one
-

UTF8string ( const std::string& str);

Now (according to what I understand from your explanation), this
constructor should be a legal candidate for the expression :

UTF8string str = "Hello, world"; // The LHS must get constructed from
the RHS.

Howvever, this code fails to compile (g++ 3.4.2).

Doh, never mind: I was thinking of:

UTF8string str("Hello, world");

:)

[Old Wolf]

Kaz Kylheku wrote:

Neelesh Bodas wrote:

IMHO, const char* constructor is the _only_ possible match. The other
constructor simply cannot match, since it will require _two_ user
defined conversions : const char[] --> std::string --> UTF8string

We are talking about the line:

UTF8string str = "Hello, world!";

In calling the const std::string & constructor, there is only one
conversion involved.

There is a second conversion going on, from std::string to
UTF8String object. But the constructor call /is/ that conversion.

The statement

T t = x;

is treated as

T t(( T(x) ));

if x is not of type T (I used double brackets to avoid
writing a function declaration).
So there are in fact two conversions.
The following only has one conversion though:

UTF8string str("Hello, world!");