• Advertisement
Sign in to follow this  

Is there a way to only disable boost debug checks?

This topic is 2997 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have added boost::shared_array in some places to my code instead of plain arrays,I don't know if this is the cause but it seems in debug mode the exe runs alot slower at around 6-7 fps.In release mode everything is lighting fast. Is there an easy way to confirm this?Like a compiler flag to disable all checks in boost or something?

Share this post


Link to post
Share on other sites
Advertisement
I seriously doubt it's because of boost. What you described seems quite normal for debug mode, almost always due to the debug versions of malloc/free and new/delete.

In any case, I don't think boost has such an option, but you'd be better off asking on the boost mailing list.


One thing you could do is define _NDEBUG at the project scope. This will disable all asserts. But it's most likely malloc/free. Another thing you could do is run a profiler.

Share this post


Link to post
Share on other sites
Quote:
Original post by Black Knight
I have added boost::shared_array in some places to my code instead of plain arrays,I don't know if this is the cause but it seems in debug mode the exe runs alot slower at around 6-7 fps.In release mode everything is lighting fast.
Seeing you're pinning this on shared_array, I'm assuming your debug performance was acceptable back when you used plain arrays?
You could try running it through a profiler like CodeAnalyst to make sure this is the culprit.

Which compiler are you using? I had similar problems just using good old STL containers/iterators on MSVC due to all the debug checks going on :/
These days they even do bounds checking in your release builds unless you opt out.

Share this post


Link to post
Share on other sites
I am using visual studio 2008 and yes after some more digging I guess std::vector<boost::shared_ptr<T>>s and shared_ptr are the cause.
Adding _NDEBUG didnt make any difference.Maybe its the optimization settings but if I enable them I will lose debugging.
I tried setting runtime checks to the same setting as release that didn't make any difference either.

Share this post


Link to post
Share on other sites
Tried putting
#define _HAS_ITERATOR_DEBUGGING 0
to one of my cpp files that use extensive iterators and stuff but the game crashes on startup at a different cpp file on a vector.push_back.

Works as usual if I remove it.

Share this post


Link to post
Share on other sites
Yea, that's why I said to put it in stdafx.h :)

It's going to be screwy if it's defined in one file but not another because it's going to result in vector having a different structure across translation units.

Share this post


Link to post
Share on other sites
Quote:
Hmm I don't have a stdafx.h in my project.Should I put it in one of the stdafx.h files inside visual studio?
If you want a macro to apply to your project globally, you can just add it to Properties->Configuration Properties->C/C++->Preprocessor->Preprocessor Definitions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Black Knight
Maybe its the optimization settings but if I enable them I will lose debugging.
I think the 2008 compiler can now actually enable optimisation and debug generation at the same time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
Quote:
Original post by Black Knight
Maybe its the optimization settings but if I enable them I will lose debugging.
I think the 2008 compiler can now actually enable optimisation and debug generation at the same time.


Older versions can too. Just make sure you output a program database from the release build (edit and continue won't work with optimizations).

The main downside of doing that is debugging gets harder - for example variables may get optimized into registers and the debugger will think they are still on the stack. If you're comfortable reading disassembly it's not too hard to debug it if you need to though.

Also you can apply optimization settings per file (or per function with #pragma optimize). That lets you optimize the most important bits of the program, while leaving the rest easily debugable.

Share this post


Link to post
Share on other sites
Am I going blind or did no one mention BOOST_DISABLE_ASSERTS?

Share this post


Link to post
Share on other sites
I mentioned _NDEBUG earlier, which should disable all boost asserts, as well as all non-boost asserts.

Share this post


Link to post
Share on other sites
There are two problems with that. 1) if BOOST_ENABLE_ASSERT_HANDLER is defined then boost's asserts don't depend on assert(). 2) The preprocessor definition you're thinking about is actually NDEBUG, not _NDEBUG.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement