The rules of C++ are designed to guarantee that type errors are impossible. Casting, however, subverts the type system and can lead to pesky errors in compiled code. This chapter explains why it’s a good idea to forgo casting as much as possible in C++.
Effective C++: Minimize casting
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
On one hand we read that:
“type errors are impossible”
but on the other that:
“[..] casts subvert the type system. That can lead to all kinds of trouble”
So – let’s conclude – in C++ there are no “errors” but “troubles”.
The author does not explain that the “troubles” are result of the wrong language design and not only programmer’s style. Many of them are eliminated by modern programming languages (Ada, Eiffel, Oberon).
The author first should read “A Critique of C++” by Ian Joyner and “The Darker Side of C++” by Markku Sakkinen
before making such as funny statements. See:
http://www.kcl.ac.uk/kis/support/cc/fortran/cpp/cpp.html
Marko
You know who the author of this article is? It’s Scott Meyer! You’d really have a hard time finding someone more experienced with the language C++ and its intricacies…
The author does not explain that the “troubles” are result of the wrong language design and not only programmer’s
style. Many of them are eliminated by modern programming languages (Ada, Eiffel, Oberon).
What I absolutely admire about Ada, Eiffel, and Oberon, is that they managed to come become rather powerful and versatile OO languages while maintaining backwards compatibility with the enormous amounts of existing C code What a feat!
Oh wait…
Who cares what a monkey with keyboard can produce nonsence in c++ if any trained professional will do the Right Thing.
before crying “wrong language design” you should try to inform yourself about the design goals of c++. for example “Design and Evolution of C++” available in every major bookstore or library. some of these design goals make for a language design that’s inferior to the design of the-language-that-could-have-been, but that’s not wrong design, it’s just design. besides, the language-that-could-have-been is neither ada nor is it java.
> besides, the language-that-could-have-been is neither ada nor is it java.
I have to agree with this statement. There are much more advanced type systems out there than either C++’s, C#’s, or Java’s. However, this isn’t the best place to discuss language design.
There is a thread on Lambda the Ultimate (a better place to discuss language design) about static and dynamic typing. I think there are some interesting points brought up in the discussion on how a strongly typed language can be both flexible and safe, if implemented correctly.
The thread can be found here: http://lambda-the-ultimate.org/node/view/834
I figured that this thread might be of interest to those who find this article interesting.
There is a very good reason it’s called backwards compatibility.
And the more energy you put into making things work with obsolete technology, the less improvement you get.
C++ is a workable OOP construction kit. But to think it is anything more is delusional.
There are 2 books every C++ programmer should have:
The C++ Programming Language by Bjarne Stroustrup (the creator and orginal implementor of the language)
Effective C++: 55 Specific Ways to Improve Your Programs and Designs, 3rd Edition by Scott Meyers
I just want to say that Effective C++ 3rd Ed is an excellent book. I regard it as (and sorry if this offends anyone) a bible for any C++ programmer.
Take a look at “Exceptional C++ – 47 Engineering Puzzles, Programming Problems, and Solutions” by Herb Sutter. You won’t regret it. The second part of the book is not that good imho.
With “second part of the book” I mean “More Exceptional C++” by the same author.
Is tough reading.
On one hand we read that:
“type errors are impossible”
but on the other that:
“[..] casts subvert the type system. That can lead to all kinds of trouble”
So – let’s conclude – in C++ there are no “errors” but “troubles”.
No. Instead let’s conclude that you are quoting out of context, deliberately misrepresenting what the author wrote.
Same lame basic C++ stuff as usual…
Nice article, learned a few more things about the inner workings of C++.
For some particular reason I keep comming back to C (yes, sometimes even object oriented C).
C++ always seems to succeed in confusing me what’s the compiler is really doing.
Nice article, learned a few more things about the inner workings of C++.
…
C++ always seems to succeed in confusing me what’s the compiler is really doing.
That’s the essential difference between C and C++. A good C programmer can’t be a good C++ programmer until they understand what it is that the compiler is doing for them (and why, and how…)
Meyers’ books are essential reading for anyone who wants to be a good C++ programmer.
When a language is so convoluted that using type-casting can LEAD to errors…
But then I still say that C and it’s cryptic cousins exists for the sole purpose of prolonging the notion that programming is difficult… Hell, ASSEMBLY is easier than regular C, much less C++.
So I have code that looks like this:
class MsgBase
{
}
class MsgTypeA : public MsgBase
{
}
class MsgTypeB : public MsgBase
{
}
void MsgRcvrX::handleMsg( MsgBase * msg )
{
if ( dynamic_cast<MsgTypeA>(msg) )
{
// handle MsgTypeA
}
if ( dynamic_cast<MsgTypeB>(msg) )
{
// handle MsgTypeB
}
else
{
// reject unknown message
}
}
As the naming implies, MsgRcvrX is one of multiple message receivers. Is there a way I can avoid the casts in handleMsg()?