0

In python, type casting is done as: float(a) if the variable a is, say an integer and needs to be converted to float.

Now consider the following C++ code:

int a=5;
int b=10;
cout<< (float) a/b<<endl;
cout<<static_cast<float> (a/b)<<endl;
cout<<static_cast<float> (a)/b;

which gives the output:

0.5

0

0.5

In the first type cast, a is type casted to float explicitly, and then b is type casted implicitly. The final answer is of the type float.

In the second and third type cast, depending on the position of the () either a is first explicitly converted to float, then b implicitly converted and then then the final value is 0.5 or a/b is first calculated as an int, and then type casted to float, making the final value 0.

There is no ambiguity while using static_cast<type>(expr)

My question being:

Wouldn't this be a lot clearer if the first line was written like:

cout<<float(a)/b<<endl;

Eliminating any ambiguity regarding in which order the type casting will be done?

C++ has no restrictions on doing just that, and yet it isn't common practice. Rather, cout<<(int)a/b<<endl; is the prevelant form, which seems to be more ambiguous.

Why is this the case?

Another way to frame this question would be: what advantage does the (type) expression offer over type (expression)?

Aayush Mahajan
  • 3,856
  • 6
  • 25
  • 32
  • 1
    The only somewhat objective answer would be that you can't write `unsigned int(3.0)`. – MSalters Jul 16 '16 at 22:34
  • 1
    Contrary to your description, there is also no ambiguity. The expression in the second has different meaning to the other two. – Peter Jul 16 '16 at 23:14
  • `There is no ambiguity while using static_cast(expr)` - my experience says otherwise, I've seen plenty of code and SO questions where the author thought that such a cast provided the compiler with context such that, e.g, `static_cast(5/2)` returned 0.5 instead of 0. – kfsone Jul 17 '16 at 00:35

2 Answers2

2

The main advantage of (type)a over type(a) is that the first works for any type and the second doesn't. Try the following and you will elicit compiler errors;

  unsigned long x = unsigned long(3.0);
  unsigned long *y = unsigned long *(0);

Beyond that, your question is based on a completely false premise. Contrary to your description, there is no ambiguity in the meaning of any of the expressions you describe.

(float) a/b;
static_cast<float> (a/b);
static_cast<float> (a)/b;

because the second has different meaning from the other two. float)a/b and static_cast<float>(a)/b both convert a to float before performing the division. static_cast<float>(a/b) do the division and then converts the result to float.

Your real problem is that you don't understand that division a/b, when a and b are of type int, produces a result of type int.

I would also suggest not holding up Python as an exemplar of how C++ should handle such things. Python 2.x produced an integral-valued result on integral division too (albeit, with slightly different behaviour than in C++). Python 3.x introduced the so-called "true division". There was a lot of heated discussion in the Python community over that.

Peter
  • 35,646
  • 4
  • 32
  • 74
1

Another way to frame this question would be: what advantage does the (type) expression offer over type (expression)?

Actually, they are almost the same...

(type) expression is a C-style cast

and

type (expression) also casts, but has limitations with respect to certain types(int*, const char* etc); Additionally, its also a constructor call for class types.

Community
  • 1
  • 1
WhiZTiM
  • 21,207
  • 4
  • 43
  • 68