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++.
Post a Comment
Member since:
---
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
Member since:---
Member since:---
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...
Member since:
---
Member since:
---
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.
Member since:---
> 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.
Member since:
2005-07-06
Member since:
2005-07-06
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.
Member since:---
Member since:---
Member since:
---
Member since:
---
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.
Member since:
2005-07-09
Member since:2005-07-06
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.
Member since:
2005-07-12
Member since:
---
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()?
