By Skizz

2008-09-23 13:58:45 8 Comments

What does the explicit keyword mean in C++?


@coding_ninza 2017-12-20 12:19:56

Explicit conversion constructors (C++ only)

The explicit function specifier controls unwanted implicit type conversions. It can only be used in declarations of constructors within a class declaration. For example, except for the default constructor, the constructors in the following class are conversion constructors.

class A
    A(const char*, int = 0);

The following declarations are legal:

A c = 1;
A d = "Venditti";

The first declaration is equivalent to A c = A( 1 );.

If you declare the constructor of the class as explicit, the previous declarations would be illegal.

For example, if you declare the class as:

class A
    explicit A();
    explicit A(int);
    explicit A(const char*, int = 0);

You can only assign values that match the values of the class type.

For example, the following statements are legal:

  A a1;
  A a2 = A(1);
  A a3(1);
  A a4 = A("Venditti");
  A* p = new A(1);
  A a5 = (A)1;
  A a6 = static_cast<A>(1);

@curiousguy 2019-01-26 00:17:05

"assign values" We aren't discussing the assignment operator here.

@Eddie 2008-09-23 14:09:06

Suppose, you have a class String:

class String {
    String(int n); // allocate n bytes to the String object
    String(const char *p); // initializes object with char *p

Now, if you try:

String mystring = 'x';

The character 'x' will be implicitly converted to int and then the String(int) constructor will be called. But, this is not what the user might have intended. So, to prevent such conditions, we shall define the constructor as explicit:

class String {
    explicit String (int n); //allocate n bytes
    String(const char *p); // initialize sobject with string p

@Johannes Schaub - litb 2010-12-13 08:59:28

And it's worth noting that the new generalized initialization rules of C++0x will make String s = {0}; ill-formed, rather than trying to call the other constructor with a null pointer, as String s = 0; would do.

@Arbalest 2013-08-05 05:23:27

Even though this is an old question it seems worth pointing a few things out (or having someone set me straight). By making the int form, or both ctors, 'explicit' you would still have the same bug if you used String mystring('x') when you meant String mystring("x") wouldn't you? Also, from the comment above I see the improved behavior of String s = {0} over String s = 0 thanks to making the int form of the ctor 'explicit'. But, other than knowing the precedence of the ctors how do you know the intent (i.e. how to spot the bug) of this String s{0} ?

@InQusitive 2015-03-22 19:51:33

Why String mystring = 'x'; is getting converted to int?

@DavidRR 2015-04-30 13:55:50

@InQusitive: 'x'is being treated as an integer because the char data type is just a 1-byte integer.

@Maggyero 2015-08-11 20:24:40

The problem with your example is that it only works with copy initialization (using =) but not with direct initialization (without using =): the compiler will still call the String(int) constructor without generating an error if you write String mystring('x');, as @Arbalest pointed out. The explicit keyword is meant for preventing implicit conversions that happen in direct initialization and function resolution. A better solution to your example would be a simple overload of the constructor: String(char c);.

@mp31415 2017-11-16 18:46:53

To avoid confusion with char argument delete the char constructor: String(char n) = delete;

@curiousguy 2018-06-12 22:23:11

@user194715 And before = delete programmers would just have added a private overloaded function.

@amithm7 2019-05-16 10:37:25

Why the conversion is not to String but to int? As 'x' is assigned to an object of class String.

@Skizz 2008-09-23 13:59:04

The compiler is allowed to make one implicit conversion to resolve the parameters to a function. What this means is that the compiler can use constructors callable with a single parameter to convert from one type to another in order to get the right type for a parameter.

Here's an example class with a constructor that can be used for implicit conversions:

class Foo
  // single parameter constructor, can be used as an implicit conversion
  Foo (int foo) : m_foo (foo) 

  int GetFoo () { return m_foo; }

  int m_foo;

Here's a simple function that takes a Foo object:

void DoBar (Foo foo)
  int i = foo.GetFoo ();

and here's where the DoBar function is called.

int main ()
  DoBar (42);

The argument is not a Foo object, but an int. However, there exists a constructor for Foo that takes an int so this constructor can be used to convert the parameter to the correct type.

The compiler is allowed to do this once for each parameter.

Prefixing the explicit keyword to the constructor prevents the compiler from using that constructor for implicit conversions. Adding it to the above class will create a compiler error at the function call DoBar (42). It is now necessary to call for conversion explicitly with DoBar (Foo (42))

The reason you might want to do this is to avoid accidental construction that can hide bugs. Contrived example:

  • You have a MyString(int size) class with a constructor that constructs a string of the given size. You have a function print(const MyString&), and you call print(3) (when you actually intended to call print("3")). You expect it to print "3", but it prints an empty string of length 3 instead.

@maccullt 2008-09-24 01:23:40

nice write up, you might want to mention multi-arg ctors with default params can also act as single arg ctor, e.g., Object( const char* name=NULL, int otype=0).

@Michael Burr 2009-08-26 17:47:04

I think it should also be mentioned that one should consider making single argument constructors explicit initially (more or less automatically), and removing the explicit keyword only when the implicit conversion is wanted by design. I think contructors should be explicit by default with an 'implicit' keyword to enable them to work as implicit conversions. But that's not how it is.

@thecoshman 2011-02-13 15:32:39

oooh, so basically, when you say a parameter for a function is explicit, your saying that it HAS to be this type, it can't be converted into that type... right?

@Christian Severin 2011-06-17 12:12:42

@thecoshman: You don't declare a parameter explicit -- you declare a constructor explicit. But yes: your parameters of type Foo have to be constructed explicitely, they won't be silently constructed by just plugging their constructor's parameters into the function.

@Larry 2012-07-10 12:52:20

Just an FYI that when calling "print(3)" in your example, the function needs to be "print(const MyString &"). The "const" is mandatory here because 3 is converted to a temporary "MyString" object and you can't bind a temporary to a reference unless it's "const" (yet another in a long list of C++ gotchas)

@Arbalest 2012-12-15 00:53:41

For completeness sake, I am adding that in addition to parameter conversion the explicit keyword here will also prevent the use of assignment form of a copy ctor (e.g., Foo myFoo = 42;) and require the explicit forms Foo myFoo = Foo(42); or Foo myFoo(42);

@Skizz 2013-10-02 13:48:05

@deimus: 'void main()' is not legal C/C++.

@meteors 2013-11-14 11:12:35

@Skizz I'm new to C++. I didn't got two points in your answer can you please explain. 1. "The compiler is allowed to do this once for each parameter." what does this line mean? does it imply that calling DoBar(42) again will cause some error. and 2. : m_foo (foo) what does this mean? I've always seen : used only for inheritance never in any function definition.

@Skizz 2013-11-17 21:38:05

@meteors: the : m_foo (foo) is an initialiser list and is only valid for constructors, note the name of the function is the same as the class. You can call DoBar (42) as often as you want. Say you had a function void Thing (Class1 c); and Class1 had a constructor Class1 (Class2 d) and Class2 had a constructor Class2 (int e) then calling Thing (314) would be invalid as there are two implicit conversions required for the parameter, the first from int to Class2, the second from Class2 to Class1.

@Rushil Paul 2014-06-20 00:10:38

@Skizz I didn't quite understand the last line. You expect it to print "3", but it prints an empty string of length 3 instead.. Why would you expect it to print "3" ? Wouldn't you rather write print("3"); if you wanted it to print "3" ? print("3"); would have the compiler searching for a constructor that takes a single const char[2] argument and print(3) would have it searching for a ctor that takes a single int argument (which it does find as expected).

@Skizz 2014-06-20 08:04:54

@Rushil: Does this help: int value=5;print(value); Would you expect it to output the value of value? What you'll get is a string with 5 spaces.

@Rushil Paul 2014-06-20 12:33:40

@Skizz It's the same thing. You are passing an int. You will get a string with 5 spaces, which is expected.

@Skizz 2014-06-20 12:54:59

@Rushil: Yes, I know that's the expected behaviour, but you know about the implicit conversion because I've told you about it. If this is the only code you're looking at (doing some maintenance on unfamiliar code, say) then you'd need to view more code to discover the implicit conversion to explain the reason for getting five spaces outputted instead of 5. In python, this would output '5' and not ' ' but here it's the other way around. What I'm trying to say is that implicit conversions are hidden from the user and thus a cause for unexpected results.

@TemplateRex 2014-09-14 13:20:01

@MichaelBurr When doing so by design, I use a comment /* implicit */ in front of all such constructors and conversion operators. Makes it easy to grep for. But explicit by default would be nicer.

@Persixty 2015-01-05 16:06:42

If I had a vote there'd be a keyword implicit that was on by default. Stepping over the tongue twister that if it weren't explicitly implicit it should be implicit that it is explicit... It's frankly inconsistent design that class members are private: unless you declare public: to protect you but singleton constructors are conversion constructors by default. Which poses the most risk and which would result in the least typing? Always. Always make the programmer take the safety off.

@sop 2015-02-20 13:29:05

Isn't there a missing const at GetFoo function? int GetFoo() const

@Skizz 2015-02-20 15:02:07

@sop: In this instance the 'const' makes no difference to the compiled program, the only issue is that some compilers will complain if 'this' was a const object. For the purposes of this answer and what I was demonstrating, leaving it off is not a big problem but if you're trying to be strict about 'const'ness then it should be added.

@PC Luddite 2015-08-11 09:06:40

Saying that the compiler is "allowed" to make one implicit conversion is ambiguous. Does that mean that the compiler may choose not to make the conversion but instead show an error?

@Skizz 2015-08-11 13:52:16

@ThePcLuddite: By that I meant the compiler will prefer no conversion rather than doing a conversion, so it won't do the conversion if there's an option to avoid doing so (for example, if there's an overloaded choice of functions) and it won't ever chain conversions together (that is, create an intermediary object). I don't think it'll ever generate an error. English is such an ambiguous language sometimes! Hmmm, what would happen if an object could be converted into one of multiple objects and each one was a valid type (via overloading). I feel that'd be an error but need to check.

@Kenji 2016-07-07 18:03:58

Why the hell any sane person allows such an implicit conversion is beyond me...

@Pavel 2017-05-04 10:09:47

Example of a bug caused by non-explicit constructor that results in totally unexpected results: Why is #include<string> preventing a stack overflow error here?

@Jarrod Smith 2017-11-09 20:30:34

"constructors callable with a single parameter" just confirming: this implies that the explicit keyword has no effect on multi-param constructors (default values notwithstanding)?

@curiousguy 2019-01-26 02:25:47

@JarrodSmith The explicit keyword was created specifically to deal only with the unique special case of one argument callable constructors (able to be called with one arg) that are treated as declaring an implicit conversion, as a side effect; there was no need for it in any other case: no other syntax creates an implicit conversion as a side effect (the sole purpose of operator T() is to create one such conversion). But C++ evolved since, with a new syntax to initialize objects that doesn't look like a function declaration: T x{args};

@curiousguy 2019-01-26 02:30:26

C++ is often criticize for getting pretty much everything wrong, very often with patently inane arguments (like typedef is bad and weak typing, virtual should be the default...). One area where Stroustrup got it wrong is the one argument ctor confusion. explicit is only a partial fix. I know that even committee members didn't knew the semantics of one arg ctors, misread (or never read) the spec, and were surprised to discover what a one arg ctor implied. But when concepts and syntaxes are overloaded to mean different things, it's almost un-fixable.

@selfboot 2016-08-20 12:45:16

Cpp Reference is always helpful!!! Details about explicit specifier can be found here. You may need to look at implicit conversions and copy-initialization too.

Quick look

The explicit specifier specifies that a constructor or conversion function (since C++11) doesn't allow implicit conversions or copy-initialization.

Example as follows:

struct A
    A(int) { }      // converting constructor
    A(int, int) { } // converting constructor (C++11)
    operator bool() const { return true; }

struct B
    explicit B(int) { }
    explicit B(int, int) { }
    explicit operator bool() const { return true; }

int main()
    A a1 = 1;      // OK: copy-initialization selects A::A(int)
    A a2(2);       // OK: direct-initialization selects A::A(int)
    A a3 {4, 5};   // OK: direct-list-initialization selects A::A(int, int)
    A a4 = {4, 5}; // OK: copy-list-initialization selects A::A(int, int)
    A a5 = (A)1;   // OK: explicit cast performs static_cast
    if (a1) cout << "true" << endl; // OK: A::operator bool()
    bool na1 = a1; // OK: copy-initialization selects A::operator bool()
    bool na2 = static_cast<bool>(a1); // OK: static_cast performs direct-initialization

//  B b1 = 1;      // error: copy-initialization does not consider B::B(int)
    B b2(2);       // OK: direct-initialization selects B::B(int)
    B b3 {4, 5};   // OK: direct-list-initialization selects B::B(int, int)
//  B b4 = {4, 5}; // error: copy-list-initialization does not consider B::B(int,int)
    B b5 = (B)1;   // OK: explicit cast performs static_cast
    if (b5) cout << "true" << endl; // OK: B::operator bool()
//  bool nb1 = b2; // error: copy-initialization does not consider B::operator bool()
    bool nb2 = static_cast<bool>(b2); // OK: static_cast performs direct-initialization

@dekuShrub 2018-04-18 10:21:58

Yes! Studying the example and the description of the keyword on cppreference is the best way to understand explicit I think.

@curiousguy 2018-06-13 00:07:54

explicit operator bool() vs. if is a special case. There is no way to reproduce it with user defined Bool, explicit operator Bool() and a function called If.

@Helixirr 2013-05-14 09:28:39

The explicit-keyword can be used to enforce a constructor to be called explicitly.

class C{
    explicit C(void) = default;

int main(void){
    C c();
    return 0;

the explicit-keyword in front of the constructor C(void) tells the compiler that only explicit call to this constructor is allowed.

The explicit-keyword can also be used in user-defined type cast operators:

class C{
    explicit inline operator bool(void) const{
        return true;

int main(void){
    C c;
    bool b = static_cast<bool>(c);
    return 0;

Here, explicit-keyword enforces only explicit casts to be valid, so bool b = c; would be an invalid cast in this case. In situations like these explicit-keyword can help programmer to avoid implicit, unintended casts. This usage has been standardized in C++11.

@6502 2014-02-19 21:25:43

C c(); in the first example doesn't mean what you think it means: it's the declaration of a function named c that takes no parameters and returns an instance of C.

@Justin Time 2016-02-10 18:35:40

explicit operator bool() is also the C++11 version of safe bool, and can be used implicitly in condition checks (and only in condition checks, as far as I'm aware). In your second example, this line would also be valid in main(): if (c) { std::cout << "'c' is valid." << std:: endl; }. Apart from this, though, it can't be used without explicit casting.

@curiousguy 2018-06-13 00:20:54

"constructor to be called explicitly" no

@curiousguy 2018-06-13 00:21:34

@JustinTime It's an inane, broken version of the safe bool. The whole idea of explicit implicit conversion is absurd.

@Justin Time 2018-06-19 07:14:32

@curiousguy True. It seems a bit like a kludge, aimed more at being easily remembered (likely in the hopes of that translating to frequently used) than at following English logic, and designed to not be outright incompatible with previous safe bool implementations (so you're less likely to break something if you swap it in). IMO, at least.

@Pixelchemist 2015-07-10 23:48:58

The keyword explicit accompanies either

  • a constructor of class X that cannot be used to implicitly convert the first (any only) parameter to type X

C++ [class.conv.ctor]

1) A constructor declared without the function-specifier explicit specifies a conversion from the types of its parameters to the type of its class. Such a constructor is called a converting constructor.

2) 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. A default constructor may be an explicit constructor; such a constructor will be used to perform default-initialization or valueinitialization (8.5).

  • or a conversion function that is only considered for direct initialization and explicit conversion.

C++ [class.conv.fct]

2) A conversion function may be explicit (7.1.2), in which case it is only considered as a user-defined conversion for direct-initialization (8.5). Otherwise, user-defined conversions are not restricted to use in assignments and initializations.


Explicit conversion functions and constructors can only be used for explicit conversions (direct initialization or explicit cast operation) while non-explicit constructors and conversion functions can be used for implicit as well as explicit conversions.

                                 explicit conversion          implicit conversion

 explicit constructor                    yes                          no

 constructor                             yes                          yes

 explicit conversion function            yes                          no

 conversion function                     yes                          yes


Example using structures X, Y, Z and functions foo, bar, baz:

Let's look at a small setup of structures and functions to see the difference between explicit and non-explicit conversions.

struct Z { };

struct X { 
  explicit X(int a); // X can be constructed from int explicitly
  explicit operator Z (); // X can be converted to Z explicitly

struct Y{
  Y(int a); // int can be implicitly converted to Y
  operator Z (); // Y can be implicitly converted to Z

void foo(X x) { }
void bar(Y y) { }
void baz(Z z) { }

Examples regarding constructor:

Conversion of a function argument:

foo(2);                     // error: no implicit conversion int to X possible
foo(X(2));                  // OK: direct initialization: explicit conversion
foo(static_cast<X>(2));     // OK: explicit conversion

bar(2);                     // OK: implicit conversion via Y(int) 
bar(Y(2));                  // OK: direct initialization
bar(static_cast<Y>(2));     // OK: explicit conversion

Object initialization:

X x2 = 2;                   // error: no implicit conversion int to X possible
X x3(2);                    // OK: direct initialization
X x4 = X(2);                // OK: direct initialization
X x5 = static_cast<X>(2);   // OK: explicit conversion 

Y y2 = 2;                   // OK: implicit conversion via Y(int)
Y y3(2);                    // OK: direct initialization
Y y4 = Y(2);                // OK: direct initialization
Y y5 = static_cast<Y>(2);   // OK: explicit conversion

Examples regarding conversion functions:

X x1{ 0 };
Y y1{ 0 };

Conversion of a function argument:

baz(x1);                    // error: X not implicitly convertible to Z
baz(Z(x1));                 // OK: explicit initialization
baz(static_cast<Z>(x1));    // OK: explicit conversion

baz(y1);                    // OK: implicit conversion via Y::operator Z()
baz(Z(y1));                 // OK: direct initialization
baz(static_cast<Z>(y1));    // OK: explicit conversion

Object initialization:

Z z1 = x1;                  // error: X not implicitly convertible to Z
Z z2(x1);                   // OK: explicit initialization
Z z3 = Z(x1);               // OK: explicit initialization
Z z4 = static_cast<Z>(x1);  // OK: explicit conversion

Z z1 = y1;                  // OK: implicit conversion via Y::operator Z()
Z z2(y1);                   // OK: direct initialization
Z z3 = Z(y1);               // OK: direct initialization
Z z4 = static_cast<Z>(y1);  // OK: explicit conversion

Why use explicit conversion functions or constructors?

Conversion constructors and non-explicit conversion functions may introduce ambiguity.

Consider a structure V, convertible to int, a structure U implicitly constructible from V and a function f overloaded for U and bool respectively.

struct V {
  operator bool() const { return true; }

struct U { U(V) { } };

void f(U) { }
void f(bool) {  }

A call to f is ambiguous if passing an object of type V.

V x;
f(x);  // error: call of overloaded 'f(V&)' is ambiguous

The compiler does not know wether to use the constructor of U or the conversion function to convert the V object into a type for passing to f.

If either the constructor of U or the conversion function of V would be explicit, there would be no ambiguity since only the non-explicit conversion would be considered. If both are explicit the call to f using an object of type V would have to be done using an explicit conversion or cast operation.

Conversion constructors and non-explicit conversion functions may lead to unexpected behaviour.

Consider a function printing some vector:

void print_intvector(std::vector<int> const &v) { for (int x : v) std::cout << x << '\n'; }

If the size-constructor of the vector would not be explicit it would be possible to call the function like this:


What would one expect from such a call? One line containing 3 or three lines containing 0? (Where the second one is what happens.)

Using the explicit keyword in a class interface enforces the user of the interface to be explicit about a desired conversion.

As Bjarne Stroustrup puts it (in "The C++ Programming Language", 4th Ed., 35.2.1, pp. 1011) on the question why std::duration cannot be implicitly constructed from a plain number:

If you know what you mean, be explicit about it.

@bruziuz 2015-01-23 09:26:52

Constructors append implicit conversion. To suppress this implicit conversion it is required to declare a constructor with a parameter explicit.

In C++11 you can also specify an "operator type()" with such keyword With such specification you can use operator in terms of explicit conversions, and direct initialization of object.

P.S. When using transformations defined BY USER (via constructors and type conversion operator) it is allowed only one level of implicit conversions used. But you can combine this conversions with other language conversions

  • up integral ranks (char to int, float to double);
  • standart conversions (int to double);
  • convert pointers of objects to base class and to void*;

@Gautam 2013-10-08 14:43:46

This answer is about object creation with/without an explicit constructor since it is not covered in the other answers.

Consider the following class without an explicit constructor:

class Foo
    Foo(int x) : m_x(x)

    int m_x;

Objects of class Foo can be created in 2 ways:

Foo bar1(10);

Foo bar2 = 20;

Depending upon the implementation, the second manner of instantiating class Foo may be confusing, or not what the programmer intended. Prefixing the explicit keyword to the constructor would generate a compiler error at Foo bar2 = 20;.

It is usually good practice to declare single-argument constructors as explicit, unless your implementation specifically prohibits it.

Note also that constructors with

  • default arguments for all parameters, or
  • default arguments for the second parameter onwards

can both be used as single-argument constructors. So you may want to make these also explicit.

An example when you would deliberately not want to make your single-argument constructor explicit is if you're creating a functor (look at the 'add_x' struct declared in this answer). In such a case, creating an object as add_x add30 = 30; would probably make sense.

Here is a good write-up on explicit constructors.

@SankararaoMajji 2012-11-21 02:36:55

The explicit keyword makes a conversion constructor to non-conversion constructor. As a result, the code is less error prone.

@n611x007 2017-01-25 00:15:23

straight answer if you know c++, if you not you can go to cjm's answer...

@fmuecke 2009-10-01 22:00:21

This has already been discussed (what is explicit constructor). But I must say, that it lacks the detailed descriptions found here.

Besides, it is always a good coding practice to make your one argument constructors (including those with default values for arg2,arg3,...) as already stated. Like always with C++: if you don't - you'll wish you did...

Another good practice for classes is to make copy construction and assignment private (a.k.a. disable it) unless you really need to implement it. This avoids having eventual copies of pointers when using the methods that C++ will create for you by default. An other way to do this is derive from boost::noncopyable.

@v010dya 2015-10-02 07:08:33

This post is written in 2009. Today you don't declare them as private, but rather say = delete.

@David Cabrera 2017-09-26 15:17:54

@fmuecke the link is dead, the question was deleted

@cjm 2008-09-23 16:37:12

In C++, a constructor with only one required parameter is considered an implicit conversion function. It converts the parameter type to the class type. Whether this is a good thing or not depends on the semantics of the constructor.

For example, if you have a string class with constructor String(const char* s), that's probably exactly what you want. You can pass a const char* to a function expecting a String, and the compiler will automatically construct a temporary String object for you.

On the other hand, if you have a buffer class whose constructor Buffer(int size) takes the size of the buffer in bytes, you probably don't want the compiler to quietly turn ints into Buffers. To prevent that, you declare the constructor with the explicit keyword:

class Buffer { explicit Buffer(int size); ... }

That way,

void useBuffer(Buffer& buf);

becomes a compile-time error. If you want to pass a temporary Buffer object, you have to do so explicitly:


In summary, if your single-parameter constructor converts the parameter into an object of your class, you probably don't want to use the explicit keyword. But if you have a constructor that simply happens to take a single parameter, you should declare it as explicit to prevent the compiler from surprising you with unexpected conversions.

@pqnet 2017-06-26 13:18:40

useBuffer expects an lvalue for his argument, useBuffer(Buffer(4)) will not work either because of it. Changing it to take a const Buffer& or Buffer&& or just Buffer would make it work.

Related Questions

Sponsored Content

22 Answered Questions

1 Answered Questions

[SOLVED] The Definitive C++ Book Guide and List

  • 2008-12-23 05:23:56
  • grepsedawk
  • 2186313 View
  • 4248 Score
  • 1 Answer
  • Tags:   c++ c++-faq

36 Answered Questions

8 Answered Questions

21 Answered Questions

[SOLVED] What is the "-->" operator in C++?

7 Answered Questions

36 Answered Questions

[SOLVED] Why is "using namespace std;" considered bad practice?

8 Answered Questions

[SOLVED] What is The Rule of Three?

5 Answered Questions

[SOLVED] What is the copy-and-swap idiom?

Sponsored Content