ctor: Why does 'explicit' prevent assignment construction? - c++

Question

I've got a class ByteArray defined like this:
class ByteArray
{
public:
explicit ByteArray( unsigned int uiSize = 0 );
explicit ByteArray( const char * ucSource );
ByteArray( const ByteArray & other );
ByteArray & operator=( const char * ucSource );
ByteArray & operator=( const ByteArray & other );
}
While almost everything works, constructing a ByteArray by assignment doesn't compile.
ByteArray ba1( 5 ); // works
ByteArray ba2( ba1 ); // works
ByteArray ba3( "ABC" ); // works
ByteArray ba4; // works
ba4 = "ABC"; // works
ByteArray ba5 = "ABC"; // <<<----- doesn't compile!
The compiler gives me a Cannot convert 'const char *' to 'ByteArray'.
However, the "assignment-constructor" should be the same as the copy-constuktor, ie. the ba5 line should compile just as the ba3 line--- in contrast to the construction of ba4 and subsequent assignment. So, I'm not quite sure what problem the compiler is having.
I know that a solution would be to remove the explicit in front of the 3rd ctor. I would rather understand what's going on first, though...
Edit:
The answer states it nicely: ByteArray ba5 = "ABC"; would get compiled as ByteArray ba5( ByteArray("ABC") ); --- NOT as ByteArray ba5("ABC"); as I thought it would. Obvious, but sometimes you need someone to point it out. Thanks everyone for your answers!
Why use 'explicit' anyway? Because there is an ambiguity between unsigned int and const char *. If I call ByteArray ba( 0 ); both ctors would be able to handle that, so I need to forbid the implicit conversion and make it explicit.

Answer 1

ByteArray ba5 = "ABC"; is copy initialization, not assignment.
Think of it as
ByteArray ba5(ByteArray("ABC"));
or at least that's what the compiler sees. It's illegal in your case because of the explicit property of the constructor - the compiler wants to use that conversion constructor to perform copy initialization, but it can't because you didn't explicitly use it.

Answer 2

If you don't use explicit keyword, compiler is allowed to convert initialization using = (copy initialization) into initialization using constructor. But sometimes you don't want this behavior and thus you use explicit keyword to avoid this conversion. So you are actually getting the intended result.
Some examples that can be restricted with explicit constructor are
explicit T(const other_type &other);
T object = other;
f(other); // if f recieves object by value
return other; // if function returns object by value
catch ( T other);
T array [ N ] = { other };

Answer 3

C++11 12.3.1/2 "Conversion by constructor" says:
An explicit constructor constructs objects just like non-explicit constructors, but does so only where the direct-initialization syntax (8.5) or where casts (5.2.9, 5.4) are explicitly used.
The form:
ByteArray ba5 = "ABC";
Is copy-initialization (per 8.5/14), not direct-initialization (ByteArray ba3( "ABC" )) (per 8.5/15), so an explicit constructor cannot be used.

Answer 4

C++ has two types of initialization, copy initialization and
direct initialization. In the case of copy initialization, the
formal rules say that the copy constructor should be used; if
the expression doesn't have the correct type, it will be
converted. (The compiler is allowed to elide the extra copy,
but it still must ensure that the code is legal without the
eliding.) The initialization signaled by an = sign (which in
this case is not the assignment operator) uses copy
initialization, as does passing a parameter or returning
a value, or throwing or catching an exception. The
initialization which is marked by parentheses or braces (in
C++11) is direct initialization, as is the initialization in
a new expression, base and member initialization, and the
various explicit conversions (static_cast, etc.).
For actual assignment, of course, the rules are those of
a function call (which is what it is—no new variable is
constructed). In your case, ba4 = "ABC"; works because you
have an assignment operator which takes a char const*; no
implicit conversion is necessary.
(And while I'm at it: I'd avoid explicit on a copy
constructor. I'm not sure exactly what it means, and I'm not
sure that anyone else is either—the purpose of explicit
is to prevent the constructor from being used in implicit
conversions, and of course, the copy constructor can't be used
in any conversions anyway.)

Answer 5

The answers provided so far give insight into why the code doesn't work. But that doesn't explain why it shouldn't work.
Copy initialization is a way of initialising variables. Explicit is a way of ensuring that implicit conversions don't happen in construction or assignment. In my experience copy initialization always behaves the same way as direct initialization (though I don't know if this is guarenteed).
Why should the presence of "explicit" stop copy initialization being valid? Or, looking at it the other way, how can I get copy initialization to work with explict constructors? If not possible then surely this is a defect in the language specification - there doesn't seem to be any disadvantage to enabling it, providing the relevant functions are declared and defined.