Need some info on this cast

[techie_san778]

Dear Friends,

I came across a cast in one text :
static_cast<float>(n). All i know is this converts n to float. But what is static_cast ?? Please help..

San.

[Elkvis]

Casting is the act of converting an object from one type to another. static_cast is simply a feature of the C++ language that does it in a safe way.

[techie_san778]

float(n) also converts n to float, what's specific about static_cast<float> ?? @Elkvis : You said it does the casting in safe way..Could you please elaborately explain ??

[Elkvis]

float(n) makes a new object that is a float representation of n, whereas static_cast tells the compiler to interpret the existing object as the new type.

[Elysia]

Well... not exactly.
The standard says that:

If the expression list is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4).

In this case:
Essentially, float(n) == (float)n == static_cast<float>(n)

If the expression "n" is a comma list of parameters, then the standard says:

If the expression list specifies more than a single value, the type shall be a class with a suitably declared constructor (8.5, 12.1), and the expression T(x1, x2, ...) is equivalent in effect to the declaration T t(x1, x2, ...); for some invented temporary variable t, with the result being the value of t as a prvalue

[techie_san778]

Sorry Elysia, not much was clear in the "language of standards". I wanted code that demonstrates the difference between the two casts and that would give a more clear picture. Is that possible ??

[laserlight]

I wanted code that demonstrates the difference between the two casts and that would give a more clear picture. Is that possible ?

The thing here is to understand that the C-style and function-style casts can be used for more kinds of conversions than static_cast. This means that the appearance of such a cast provides less information to the reader than a static_cast, because it does not tell the reader which of the possible kinds of conversions was intended.

So if you want code that demonstrates the difference, you should think about situations where static_cast won't work, yet a C-style or function-style cast will work. For example:

#include <iostream>

void legacy_foo(char* str)
{
    // ...
}

int main()
{
    const char* text = "hello";
    legacy_foo(text);
}

Imagine that legacy_foo is some legacy function that is not const-correct: it doesn't actually modify the contents of the null terminated string, yet str was not declared to be a pointer to const char. If you try to compile the above program, you probably will get an error telling you that legacy_foo expects a char* argument but you passed a const char* instead.

Assuming that you cannot fix legacy_foo's interface, you can fix this function call with a cast:

legacy_foo((char*)text);

A reader might then wonder: where did the const go? Was it a typo error or some other mistake. Upon closer inspection, the reader might be able to figure out that the removal of the const was deliberate, but it might not be immediately clear from the cast.

Rather, you could have written:

legacy_foo(const_cast<char*>(text));

and at a glance it is clear that the removal of the const must have been deliberate: not only was the const removed, but a const_cast was used. If you had tried to write:

legacy_foo(static_cast<char*>(text));

you would have seen a compile error message telling you that this use of static_cast is invalid.

[cstryx]

float(n) calls the constructor for float to create a new float from n, (float)n casts n to a type of float, but that is a C style cast which implicitly chooses the most appropriate cast for the job (with the exception of dynamic_cast). Sometimes the C cast doesn't choose the C++ style cast that you intend either, so in a sense, it's not as safe.

C++ has 4 casts:
- static_cast
- dynamic_cast
- const_cast
- reinterpret_cast

[Elysia]

float(n) calls the constructor for float to create a new float from n...

No, it does not. It is exactly equivalent to a C-style cast in this case, as I showed above. The standard explicitly says so.

[cstryx]

No, it does not. It is exactly equivalent to a C-style cast in this case, as I showed above. The standard explicitly says so.

I'm confused by the following then:

#include <iostream>

int main()
{
   // float(n);
   (float)n;
   n = 2.7f;
   std::cout << n << std::endl;
}

This fails to compile because n is undeclared, (float)n is only a cast, yet 'n' is not declared, so the cast for 'n' is unknown. Uncomment the top line and the functional cast is treated as an initialization for n. Either leave the (float)n uncommented out or comment it, and the code compiles fine with a temp variable n being created. Declare a variable named n at the top of the code and a redefinition error ocurrs... The functional notation still tries to make a variable out of n of type float, and the behavior is not the same as the c cast (float)n, where the statement is just ignored.

Obviously float(n) seems to invoke the default constructor (seemingly).

[laserlight]

Uncomment the top line and the functional cast is treated as an initialization for n.

That is not true. On that line, there is no cast. Rather, it is a declaration (and the definition) of n that does not perform initialisation. Yes, the syntax looks the same as a cast using functional notation, but it is semantically different. I suggest that you avoid it because it can be confusing compared to just writing:

float n;

Obviously float(n) seems to invoke the default constructor (seemingly).

Since it is not a class, float has no default constructor in the first place.

[cstryx]

That is not true. On that line, there is no cast. Rather, it is a declaration (and the definition) of n that does not perform initialisation. Yes, the syntax looks the same as a cast using functional notation, but it is semantically different. I suggest that you avoid it because it can be confusing compared to just writing:

float n;

Since it is not a class, float has no default constructor in the first place.

No, you can ignore what I said, it was late for me yesterday lol. I didn't think this was posted, and I was going to edit it all out, but I had realized that what I said was wrong long ago. I had encountered site issues (database errors) yesterday? :S So I wasn't sure whether this post was successfully posted or not...