conversion

Here's an interesting quote from "C++ Coding Standards" (Sutter / Alexandrescu) on exception specifications (taken from Item 75: Avoid exception specifications):

Quote:

---

The main problems with exception specifications are that they're only "sort of" part of the type system, they don't do what most people think, and you almost always don't want what they actually do.

...

They cause the compiler to inject additional run-time overhead in the form of implicit try/catch blocks around the function body to enforce via run-time checking that the function does in fact emit only listed exceptions (possibly none), unless the compiler can statically prove that the exception specification can never be violated in which case it is free to optimize the checking away. And exception specifications can both enable and prevent further compiler optimizations (beside the inherent overhead already described); for example, some compilers refuse to inline functions that have exception specifications.

Worst of all, however, is that exception specifications are a blunt instrument: When violated, by default they immediately terminate your program. You can register an unexpected_handler, but it's highly unlikely to help you much because you get exactly one global handler and the only way the only way the handler could avoid immediately calling terminate would be to rethrow an exeption that is permissible, but [it's hard to see how the handler could] know what exeptions might be legal without trivializing exception specifications altogether.

...

[BoostLRG]'s experience is that a throws-nothing exceptio specification (i.e., throw()) on a non-inline function "may have some benefit with some compilers." Not a stunning endorsement from one of the most highly regarded and expertly designed C++ library projects in the world.

---

RTTI does not always mean downcasting, nor ugly switches.
RTTI can be used to do horizontal casting (and should only be used for that).
RTTI can be used to implement the equivalent of Java interfaces.
It is not ugly at all (even if it is not common to use interfaces in C++), it is even better for code reuse and beautiful class design than classical C++ design.

In fact i don't use interfaces in my project, and i generally deactivate RTTI with a compiler option.
It is just a non commonly used language feature.

so, dynamic_cast is not always evil.
But typeid is always evil except to get debugging informations. It should never be used in a release version of a project.

Quote:

---

Originally Posted by KevinHall

So RTTI in many situations may be an admission of defeat. But is that evil?

---

I'm not the one who said it was...

Quote:

---

Originally Posted by Graham

I'm not the one who said it was...

---

I know you didn't. I just wanted to prevent what you said being used as an argument for the person that did make the statement.

While waiting for an explanation of why RTTI is evil, I scanned "C++ Coding Standards" and there is no item in there mentioning avoiding RTTI or dynamic_cast. However, Item 93 actually encourages the use of dynamic_cast as a safe alternative to static_cast. (It also suggests refactoring and redesign as options too as designing away downcasting is prefferable. But not everything falls under that category.)

Quote:

---

Originally Posted by KevinHall

Here's an interesting quote from "C++ Coding Standards" (Sutter / Alexandrescu) on exception specifications (taken from Item 75: Avoid exception specifications):

---

Why does violating an exception specification cause a call to terminate() at runtime? In Java, the violation of an exception specification causes a compile error which, in my opinion, is a good thing is it not?

In C++, you can't catch every exception specification violation at compile-time. For example, a DLL might throw something you didn't expect it to.

- Kevin

Quote:

---

Originally Posted by HighCommander4

Why does violating an exception specification cause a call to terminate() at runtime? In Java, the violation of an exception specification causes a compile error which, in my opinion, is a good thing is it not?

---

When an incorrect exception is thrown at runtime in a function (or function called directly or indirectly by the function) which has an exception specification, and this exception is not caught inside the function (nor inside the function called by the function), it calls the std::unexpected function which terminates the program by default (this behavior can be changed, but generally we can't do much more than terminating the program).

It's also because in C++, exception specifications are only (in the words of Sutter/Alexandrescu) "sort of" part of the type-system. Exception specifications are not strongly enforced everywhere. If exception specifications were strongly enforced, they would be safer than they currently are (but they may still have other problems).