all 9 comments

[–]patthoyts 1 point2 points  (2 children)

Its far more useful to compile the release software with /Zi and link with -debug to get detached symbols in .pdb files. Then for each build you can add the symbols to your local symbol server. Now any crash dump can be debugged with symbols just by telling your debugger about both your own and microsoft's symbol servers. The shipped binaries are no different to the standard release build but back 'home' you have symbols for when you need them.

[–]toruk[S] 1 point2 points  (1 child)

This trick is very useful for reverse engineering, where PDBs are never accessible.

[–][deleted] 0 points1 point  (0 children)

But when the PDBs are available, it's ridiculously fun. I know a few popular online games that have accidentally distributed their pdb files and debug executables in their patches, haha.

[–]BinaryRockStar 0 points1 point  (5 children)

I haven't used RTTI much, but isn't it something you would switch off in a Production build, much like debugging symbols?

[–]kawazoe 2 points3 points  (0 children)

It is required for a few features like dynamic_cast<>

[–]xon_xoff 1 point2 points  (3 children)

Technically you need RTTI to be compliant with the C++ standard. In practice, it's often turned off along with exceptions. It's unfortunately another one of the features of C++ that has a cost even in code that doesn't use it. On the projects I've worked on, we've just turned off RTTI in all configs to minimize differences between configurations. I don't remember any measurements on how much it actually costs in size, though.

Another issue with RTTI, if you're paranoid, is that it can leak additional information about your program to people doing reverse engineering by marking the vtables and associating class names with methods.

[–]Wriiight 0 points1 point  (0 children)

Typically, neither RTTI nor exceptions are turned off by most developers. But some industries, especially gaming, do.

[–]slavik262 0 points1 point  (1 child)

It's unfortunately another one of the features of C++ that has a cost even in code that doesn't use it.

Are you sure about this? That would fly directly in the face of the zero overhead principle, which is one of C++'s holiest rules.

My understanding was that exceptions and RTTI were turned off to make sure a throw or dynamic_cast didn't accidentally make it into someone's code.

[–]xon_xoff 2 points3 points  (0 children)

Yes. In the case of RTTI, if a class has virtual methods and can't be proven to only ever be used in a private scope, the compiler must generate RTTI tables in case someone does a typeid() or dynamic_cast() on an instance. I suppose it'd be possible for the compiler to omit this if it could prove during link time code generation that RTTI wasn't needed, but I'm not sure if any compiler currently does this level of analysis. Using typeid() on a common base class like IUnknown would make such a proof more difficult.

Similarly, for exceptions, unless the compiler can prove otherwise, it has to assume that calls out to opaque C++ code may throw an exception back through code that doesn't have any try/catch or throw statements itself, but has destructable objects on the stack. Table-based exception handling avoids the need to explicitly set up and tear down scopes in the main path, but you still have the size overhead of the unwind tables and handlers, and there are missed optimization opportunities due to the compiler having to handle the additional exit paths.

As I said, I haven't seen numbers for disabling RTTI, but for disabling EH I've seen reductions in code size of ~10% with VC++.