Disable generating debug symbols for certain lines in C/++?

Is it possible to specify certain blocks of code for which I do not wish debug symbols to be generated while in Debug build in VC++ 2010? So these parts can run at optimised speed, while other (logic) code blocks can be debugged?

The reason is I have to read an input file with million+ lines which is painfully slow in Debug mode, but I wouldn't like to 开发者_如何学Cuse a smaller sample input file.

Cheers, Mike

A couple suggestions:

• each C or C++ file can have options specified separately - that's obvious when you're using the command line to compile, but you can also do so in the IDE. There's no need to set up a separate project. Just right click on the file you want to have 'special' settings for and select "Properties". The big drawback to this is that it's not obvious that a particular file has different settings from the project settings, so it can be confusing when things don't seem to build like you expect after you've forgotten about the file-specific properties that have been set.
• you can try the optimize pragma (http://msdn.microsoft.com/en-us/library/chh3fb0k.aspx) to see if it will do what you want

Note that symbol generation and optimization are separate things - optimized code can have symbols generated without hurting optimization (but due to the optimizations the debugger might still be confused tracing through or setting breakpoints). But there's not much reason to try to suppress symbols for specific files (except maybe for obfuscation purposes).

Some additional things to be aware of are that there are also differences between the debug and non-debug runtimes - and you can link to only one or the other. So, if the slowness you want to get rid of is in the debug runtime, you'll have to link to the non-debug runtime which might hamper you debugging in other areas. If you're using C++ there is also the issue of debugging and safe iterators (controlled by the _HAS_ITERATOR_DEBUGGING and _SECURE_SCL macros) - you can't mix and match code that's been compiled with different settings for these iterator configurations (see Visual Studio debug iterators).

I would prefer an alternate solution (that requires less work). If you can't find one, this could work for you:

• Move the long-executing input handling code to a separate library project
• Build the library as non-debug
• Link the library into your main project
• Compile your main project as debug