What the difference between Implicit and Explicit Conversion?

And implicit cast/conversion is something the compiler will do for you. This happens automatically when it's safe for the compiler to do so. For example, conversion from char to int is generally safe. An explicit cast is where the programmer uses either an explicit c style cast [int i = (int) x] or a c++ cast [int i = static_cast<int>(x);]. Generally, you should avoid explicit casts unless you need to do them as they can shadow problems. When you do an explicit cast you are telling the compiler to put up and shut up because you know what you are doing. Of course, the compiler will then not warn you if something looks wrong (because your cast tells it not to). Use explicit casts with care.

Accepted Solution

03.11.2008 at 08:57AM PDT, ID: 21097003

Rank: Sage

1 is just a value - it doesn't have a type yet when you write it down. It will be interpreted by the compiler, and if it fits the context, it will be accepted.

>> When 1 is assigned to x, 1 is implicitily converted to data type char.

It's not "converted". A char is an integer data type, so there's no conversion needed.

>> What is difference between implicit and explicit conversion?

Implicit means that it's done by the compiler without you having to worry about it. Explicit means that you add code to do the conversion yourself (the way you want - not the way the compiler thinks it needs to be done).

>> When do we know data will be implicitily converted?

As I said, there's no conversion in this case. There's just an interpretation depending on the context. The context is an assignment to char, so the interpretation of 1 is as an int.

In this case for example :

double d = 1;

the context is an assignment to a double, so the interpretation of 1 is as a double.

>> And when do we need to explicitily convert it?

Whenever the compiler's decision is not what you wanted.

Assisted Solution

03.11.2008 at 08:58AM PDT, ID: 21097019

Rank: Guru

More is explained here: http://www.cplusplus.com/doc/tutorial/typecasting.html

03.11.2008 at 09:00AM PDT, ID: 21097039

Rank: Guru

>> 1 is just a value - it doesn't have a type yet when you write it down
In the absence of any context the compiler will assume it to be an int.

int main()
{
int * p = 1;
return 0;
}

main.cpp(3) : error C2440: 'initializing' : cannot convert from 'int' to 'int *'
1> Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast

03.11.2008 at 09:02AM PDT, ID: 21097057

Rank: Guru

>> double d = 1;
That's an implicit conversion from and int to a double.

double d = 1.0; // This involves no conversion.

int main()
{
int * p = 1.0;
return 0;
}

main.cpp(3) : error C2440: 'initializing' : cannot convert from 'double' to 'int *'

03.11.2008 at 09:09AM PDT, ID: 21097129

Rank: Sage

>> In the absence of any context the compiler will assume it to be an int.

In that case, the context is an assignment to int*. 1 is rarely a valid value for an int* (and actually, the standard doesn't say it has to be), so the use of 1 in this context is invalid, which means that 1 can't be interpreted as an int*, and thus causes an error. Since 1 can't be interpreted as int*, its type is set to the default int.

My use of the word "interpretation" over "conversion" is really just semantics - I'll admit that - but it's the way I prefer to look at it :) The reason is that the code generated for :

double d = 1;

is exactly the same as the code generated for :

double d = 1.0;

There's no trace of any conversion in the generated code. That's why I prefer to speak about "interpretation".

03.11.2008 at 09:18AM PDT, ID: 21097219

Rank: Guru

>> the use of 1 in this context is invalid, which means that 1 can't be interpreted as an int*
I know, that was exactly the point of this code, to generate an error that eluded to the type the compiler thought 1 was (maybe I should have clarified that?). On both Visual Studio and gcc it (correctly) identifies 1 as an int and 1.0 as a double (and 1.0f as a float and 1.1L as a long).

>> There's no trace of any conversion in the generated code
My compiler generates different code (all be it 1 line) :)
double d = 1.1;
0041138E fld qword ptr [__real@3ff199999999999a (415740h)]
00411394 fstp qword ptr [d]

double d = 1;
0041138E fld1
00411390 fstp qword ptr [d]

03.11.2008 at 09:35AM PDT, ID: 21097385

Rank: Sage

>> My compiler generates different code (all be it 1 line) :)

1.1 is not the same as 1 :)

03.11.2008 at 10:00AM PDT, ID: 21097662

@evilirix:

> For example, conversion from char to int is generally safe.
it is actually the other way round: conversion from int to char is safe. (int) 'a' would simply fail, wouldn't it

> Generally, you should avoid explicit casts unless you need to do them as they can shadow problems.
again, the other way round IMHO. allowing implicit cast will actually make it difficult to debug problems, while explicit conversion will show exactly what the developer meant to do (and with some proper comments, why) ...

Assisted Solution

03.11.2008 at 10:03AM PDT, ID: 21097693

Rank: Sage

>> (int) 'a' would simply fail, wouldn't it

Why ? 'a' is an integer value, so there's no problem assigning it to an int.

Conversion from int to char is also "safe", except that you have to take into account overflow (an int can store a bigger range of values than a char).

03.11.2008 at 10:04AM PDT, ID: 21097702

Rank: Sage

>> (int) 'a' would simply fail, wouldn't it

And actually (just to support what I said), take a look at getc for example :

http://www.cplusplus.com/reference/clibrary/cstdio/getc.html

It returns int, even though the int will contain a char.

03.11.2008 at 10:19AM PDT, ID: 21097847

Rank: Guru

>> it is actually the other way round: conversion from int to char is safe. (int) 'a' would simply fail, wouldn't it
No, why do you think that? 'a' is just numeric value 65 (decimal).

>> again, the other way round IMHO. allowing implicit cast will actually make it difficult to debug problems, while explicit conversion will show exactly what the developer meant to do
But then you are hiding problems. Why cast if you don't need to? Would you do this...?

typedef int mytype_t;
mytype_t a = 0;
int b = static_cast<mytype_t>(a);

If so, why? It's unnecessary. If at some point the type of mytype_t was changed to a type that was unsafe to cast to int you'd not know if you has an explicit cast. If you leave it as it is and the type changes to a type that cannot be safely cast the compiler will tell you so and you can take appropriate corrective action . Basically, explicit casting should be avoided unless absolutely necessary! Also, in C++ implicit conversion is happening all the time, even when you don't realize it, so if we follow this to conclusion we'd try to isolate and explicitly cast all instances of this... impossible!

03.11.2008 at 10:21AM PDT, ID: 21097872

Rank: Guru

>> Also, in C++ implicit conversion is happening all the time
Although, I note this Q is in the C zone only but similar is true for C (although not quite as pervasive as there is no such think as constructor casting and the likes) :)

03.11.2008 at 10:40AM PDT, ID: 21098052

>> (int) 'a' would simply fail, wouldn't it
>Why ? 'a' is an integer value, so there's no problem assigning it to an int.
in C/C++, a single character to int will still be implicit conversion, taking the ascii code of the character, indeed, I stand corrected.
which is, IMHO, a perfect example of why implicit conversion are "dangerous", as code reader, you have to be aware of that implicit possibility unless it is documented in the code OR you have some experience with it.
C# for example would not allow this implicitly, for good reasons, which I do really appreciate.

my example also was actually "bad choice", I wanted to show the (int) "string" would fail :)
same for the int->char conversion, I meant int->string ...

03.11.2008 at 10:48AM PDT, ID: 21098121

Rank: Guru

>> a perfect example of why implicit conversion are "dangerous",
But, like I've already said, in C++ (sorry to hijack this from C specifically, but it is just to make a point) they are a natural part of the langauge that you cannot avoid.

Consider the code below, which wouldn't work without implicit conversion....

                       
             struct base{ virtual ~base(){} };
struct super : base{};
 
int main()
{
	super s;
	base & b = s; // Polymorphic reference and implicit conversion
}

Open in New Window

03.11.2008 at 10:52AM PDT, ID: 21098170

Rank: Guru

And this is the same in C#, no?

                       
         
           
           
             namespace clrtest
{
    class mybase { };
    class mysuper : mybase {};
 
    class Program
    {
        public static void Main(string[] args)
        {
            mysuper s = new mysuper();
            mybase b = s;
        }
    }
}

           
         

Open in New Window

03.11.2008 at 10:54AM PDT, ID: 21098198

good point, and definitively highly useful when working with classes, but:
* you commented it... (which is GOOD)
* is indeed not what we are speaking about here (int<->char) :)

03.11.2008 at 10:58AM PDT, ID: 21098241

Rank: Guru

>> is indeed not what we are speaking about here (int<->char) :)
Well, it is because it's still an implicit conversion and I only commented it for the sake of this discussion, there is no way I'd normally comment such a line... it just isn't necessary. ;)

Ok, then what about this?

                       
         
           
           
             namespace clrtest
{
    class Program
    {
        public static void Main(string[] args)
        {
            char c = 'a';
            int n = 'a';
            n = c;
            c = n; // This is not legal in C#
        }
    }
}

           
         

Open in New Window

03.11.2008 at 10:59AM PDT, ID: 21098246

>And this is the same in C#, no?
yes, but int<->char is not allowed there, implicitly :)

03.11.2008 at 11:07AM PDT, ID: 21098341

Rank: Guru

>> yes, but int<->char is not allowed there, implicitly :)
Which is not inconsistent with anything I've said is it? All safe implicit conversions are (as is consistent with my assertion) allowed. I will concede C++ will allow the last implicit cast but then again casting it makes it no safer and also C/C++ doesn't even know whether a char is signed or unsigned (the standard leaves it as undefined -- *sigh*) so I'd expect no less :)

I accept in C# things are a little different (I also write C# for my sins -- although not if I can help it!) but this isn't C# it's C/C++ where the stabilizers have been removed :)

03.11.2008 at 12:41PM PDT, ID: 21099305

Rank: Sage