C++ style typecast ambiguity

How screwed up am I? C++ offers two typecast styles. For example, to
typecast x to an int I can do (int)x or int(x). So take a look at the
following do-nothing example:

void fcn()
{
int x, y; // Okay
x; // Okay
y = int(x); // Okay
int(x); // NOT Okay!!!!!
(int)x; // Okay
}

The compiler obviously treates int(x) as a declaration, as it should.
However, what if I want (for whatever bizarre reason) to have a non-side
effect statement consisting only of a C++ typecast? I can have such a
statement for C typecasts and every other form of expression I know of, so
why should this be an exception? It reminds me of the early days of C where
the compound operators were =+ =- =* etc. instead of the current += -+ *=
etc. Since the problem with these was seen quickly, they were changed. Oh
well, I'm probably just missing something, but any thoughts are welcome.

Thanks,
Ray

Doug
Thu Jan 03 15:56:12 CST 2008

On Thu, 3 Jan 2008 13:48:04 -0800, Ray Mitchell
<RayMitchell_NOSPAM_@MeanOldTeacher.com> wrote:

>How screwed up am I? C++ offers two typecast styles. For example, to
>typecast x to an int I can do (int)x or int(x). So take a look at the
>following do-nothing example:
>
>void fcn()
>{
> int x, y; // Okay
> x; // Okay
> y = int(x); // Okay
> int(x); // NOT Okay!!!!!
> (int)x; // Okay
>}
>
>The compiler obviously treates int(x) as a declaration, as it should.
>However, what if I want (for whatever bizarre reason) to have a non-side
>effect statement consisting only of a C++ typecast? I can have such a
>statement for C typecasts and every other form of expression I know of, so
>why should this be an exception? It reminds me of the early days of C where
>the compound operators were =+ =- =* etc. instead of the current += -+ *=
>etc. Since the problem with these was seen quickly, they were changed. Oh
>well, I'm probably just missing something, but any thoughts are welcome.

The declaration rules come from C, which obviously predates the
function-style cast syntax. As a problem, this is more commonly observed in
terms of the "most vexing parse". To "have a non-side effect statement
consisting only of a C++ typecast", you would typically cast to void, and
since void is an incomplete type, only the C-style cast will work.


--
Doug Harrison
Visual C++ MVP

Victor
Thu Jan 03 16:05:09 CST 2008

Ray Mitchell wrote:
> How screwed up am I? C++ offers two typecast styles. For example, to
> typecast x to an int I can do (int)x or int(x). So take a look at the
> following do-nothing example:
>
> void fcn()
> {
> int x, y; // Okay
> x; // Okay
> y = int(x); // Okay
> int(x); // NOT Okay!!!!!
> (int)x; // Okay
> }
>
> The compiler obviously treates int(x) as a declaration, as it should.
> However, what if I want (for whatever bizarre reason) to have a
> non-side effect statement consisting only of a C++ typecast? I can
> have such a statement for C typecasts and every other form of
> expression I know of, so why should this be an exception? It reminds
> me of the early days of C where the compound operators were =+ =- =*
> etc. instead of the current += -+ *= etc. Since the problem with
> these was seen quickly, they were changed. Oh well, I'm probably
> just missing something, but any thoughts are welcome.

Use parentheses:

(int(x));

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Ben
Thu Jan 03 16:47:57 CST 2008


"Ray Mitchell" <RayMitchell_NOSPAM_@MeanOldTeacher.com> wrote in message
news:230CCBDF-FE69-44AB-9C6F-73ED71AF0985@microsoft.com...
> How screwed up am I? C++ offers two typecast styles. For example, to
> typecast x to an int I can do (int)x or int(x). So take a look at the
> following do-nothing example:

You've missed the recommended typecast style, the template-style cast.

>
> void fcn()
> {
> int x, y; // Okay
> x; // Okay
> y = int(x); // Okay
> int(x); // NOT Okay!!!!!
> (int)x; // Okay
> }
>
> The compiler obviously treates int(x) as a declaration, as it should.
> However, what if I want (for whatever bizarre reason) to have a non-side
> effect statement consisting only of a C++ typecast? I can have such a
> statement for C typecasts and every other form of expression I know of, so
> why should this be an exception? It reminds me of the early days of C
> where
> the compound operators were =+ =- =* etc. instead of the current += -+ *=
> etc. Since the problem with these was seen quickly, they were changed.
> Oh
> well, I'm probably just missing something, but any thoughts are welcome.

What exactly is wrong with

static_cast<int>(x);

?

>
> Thanks,
> Ray

RayMitchell_NOSPAM_
Fri Jan 04 14:20:00 CST 2008



"Ben Voigt [C++ MVP]" wrote:

>
> "Ray Mitchell" <RayMitchell_NOSPAM_@MeanOldTeacher.com> wrote in message
> news:230CCBDF-FE69-44AB-9C6F-73ED71AF0985@microsoft.com...
> > How screwed up am I? C++ offers two typecast styles. For example, to
> > typecast x to an int I can do (int)x or int(x). So take a look at the
> > following do-nothing example:
>
> You've missed the recommended typecast style, the template-style cast.
>
> >
> > void fcn()
> > {
> > int x, y; // Okay
> > x; // Okay
> > y = int(x); // Okay
> > int(x); // NOT Okay!!!!!
> > (int)x; // Okay
> > }
> >
> > The compiler obviously treates int(x) as a declaration, as it should.
> > However, what if I want (for whatever bizarre reason) to have a non-side
> > effect statement consisting only of a C++ typecast? I can have such a
> > statement for C typecasts and every other form of expression I know of, so
> > why should this be an exception? It reminds me of the early days of C
> > where
> > the compound operators were =+ =- =* etc. instead of the current += -+ *=
> > etc. Since the problem with these was seen quickly, they were changed.
> > Oh
> > well, I'm probably just missing something, but any thoughts are welcome.
>
> What exactly is wrong with
>
> static_cast<int>(x);
>
> ?
>
> >
> > Thanks,
> > Ray
>
>
>



> What exactly is wrong with
>
> static_cast<int>(x);

Hi Ben,

I don't know whether or not anything is wrong with that style other than it
is very verbose and can, thus, cause some very long code lines (you know,
kind of like using the keyword auto for all automatic variable declarations).
I was merely addressing the issue of the int(x) C++ style, which is much
more compact.

Thanks,
Ray

Tamas
Mon Jan 07 15:16:28 CST 2008

Ray Mitchell wrote:

> I don't know whether or not anything is wrong with that style other than it
> is very verbose and can, thus, cause some very long code lines (you know,
> kind of like using the keyword auto for all automatic variable declarations).
> I was merely addressing the issue of the int(x) C++ style, which is much
> more compact.

Striving for the possible most compact code is not always the best
practice. Readability and the safety provided by compile-time type
checking are far more important aspects.

static_cast<> has several advantages to C-style casts. Because it's so
verbose, it's easy to see, you can't miss it. It expresses the intention
of the programmer much better. It conveys the message: "Make no mistake,
this is not a constructor here, it's a static type casting". It is also
better searchable by tools like grep.

But most importantly, static_cast doesn't allow you to shoot yourself in
the foot so easily:

void* p = 0;
int i = static_cast<int>(p);
// error C2440: 'static_cast': cannot convert from 'void *' to 'int'

Had you used (int)p, you would have introduced a fatal error on the x64
platform, and it could have cost an hour of extra debugging to fix it.

Similarly, static_cast doesn't let you cast from unrelated T* to U*
types. This adds such a high level of safety that greatly compensates
for the inconvenience of the extra typing. Besides, after a few weeks of
practice, you'll type `static_cast' as fast as `unsigned long' or
`interface'.

You may also want to know that Scott Meyers, Herb Sutter and Andrei
Alexandrescu highly recommend the use of C++-style casts in their books.
(int)x is not C++, it's C, and the reason it's still in the language is
because an enormous amount of legacy code relies on it.

Tom

RayMitchell_NOSPAM_
Mon Jan 07 16:31:02 CST 2008



"Tamas Demjen" wrote:

> Ray Mitchell wrote:
>
> > I don't know whether or not anything is wrong with that style other than it
> > is very verbose and can, thus, cause some very long code lines (you know,
> > kind of like using the keyword auto for all automatic variable declarations).
> > I was merely addressing the issue of the int(x) C++ style, which is much
> > more compact.
>
> Striving for the possible most compact code is not always the best
> practice. Readability and the safety provided by compile-time type
> checking are far more important aspects.
>
> static_cast<> has several advantages to C-style casts. Because it's so
> verbose, it's easy to see, you can't miss it. It expresses the intention
> of the programmer much better. It conveys the message: "Make no mistake,
> this is not a constructor here, it's a static type casting". It is also
> better searchable by tools like grep.
>
> But most importantly, static_cast doesn't allow you to shoot yourself in
> the foot so easily:
>
> void* p = 0;
> int i = static_cast<int>(p);
> // error C2440: 'static_cast': cannot convert from 'void *' to 'int'
>
> Had you used (int)p, you would have introduced a fatal error on the x64
> platform, and it could have cost an hour of extra debugging to fix it.
>
> Similarly, static_cast doesn't let you cast from unrelated T* to U*
> types. This adds such a high level of safety that greatly compensates
> for the inconvenience of the extra typing. Besides, after a few weeks of
> practice, you'll type `static_cast' as fast as `unsigned long' or
> `interface'.
>
> You may also want to know that Scott Meyers, Herb Sutter and Andrei
> Alexandrescu highly recommend the use of C++-style casts in their books.
> (int)x is not C++, it's C, and the reason it's still in the language is
> because an enormous amount of legacy code relies on it.
>
> Tom
>

Thanks Tom,

...very nice detailed explanation. I appreciate it.

Ray

Ulrich
Tue Jan 08 06:08:28 CST 2008

Tamas Demjen wrote:
> static_cast<> has several advantages to C-style casts. Because it's so
> verbose, it's easy to see, you can't miss it. It expresses the intention
> of the programmer much better. It conveys the message: "Make no mistake,
> this is not a constructor here, it's a static type casting".

Ahem, that's not true, at least not if you mean "this is not a constructor
invocation here". E.g. if you static_cast<std::string>("foo"), you actually
invoke the constructor here.

I think it's best not to think about builtin vs user-defined or class type,
but in on a level above it. static_cast<> creates one object from another,
no matter what type that object has (well, unless the target type is a
reference, but let's leave that aside for now). This allows template code
to be written without having to specify whether the argument must be
builtin or user-defined, just like T() yields a default-initialised[1]
object.

Uli

[1] not sure if the term 'default-initialised' is correct