Thorsten Ottosen writes:

Are you referring to a debug build?

No

What compiler?

"g++ (GCC) 4.2.1 (Debian 4.2.1-5)" The command I used was: g++ -O3 -fomit-frame-pointer x.cc I'm using Debian's "libboost-dev" package, version 1.34.1-2.

1.34 introduced a macro for tuning all the exceptions into asserts.

Hmmm I didn't explicitly define any macros, but what the compiled code contains seems to be asserts. Are asserts generally smaller/larger than throws? Thanks, -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin

Thorsten Ottosen writes:

See

http://www.boost.org/libs/ptr_container/doc/reference.html#disabling-the-use...

Ok, I just checked the preprocessed output, and exceptions are _not_ "disabled", but the boost code seems to contains tons of assertions regardless of what mode (exceptions or no_exceptions) is used.

...

Hmmm I didn't explicitly define any macros, but what the compiled code contains seems to be asserts.

Ok, you need to turn assertions off in release mode, perhaps by using -DNDEBUG=1

Well... generally the whole concept of a special no-checking-at-all "release mode" is a bit alien here. I looked at the code and it seems like the basic problem is that the boost::ptr_sequence_adapter class (at least) is somewhat over-enthusiastic in it's use of assertions: template<...> class ptr_sequence_adapter : public ptr_container_detail::reversible_ptr_container< ptr_container_detail::sequence_config, CloneAllocator > { ... const_reference operator[]( size_type n ) const { ((n < this->size()) ? static_cast<void> (0) : __assert_fail ("n < this->size()", "/usr/include/boost/ptr_container/ptr_sequence_adapter.hpp", 271, __PRETTY_FUNCTION__)); ((!this->is_null( n )) ? static_cast<void> (0) : __assert_fail ("!this->is_null( n )", "/usr/include/boost/ptr_container/ptr_sequence_adapter.hpp", 272, __PRETTY_FUNCTION__)); return *static_cast( this->c_private()[n] ); } } Especially in this case, where there are explicitly two different operations ("at" and operator[]) that allow the user to select which level of low-level safety-checking he wants, such assertions seem out of place. -Miles -- 97% of everything is grunge

Thorsten Ottosen writes:

Just about any boost library has the implicit assumption that assertions are compiled away *if the optimal efficiency/smallest code is to be gained*. ... Anyway, to justify why assertions should be disabled in release mode, I recommed:

http://www.artima.com/cppsource/deepspace.html

In particular, read the section on "The Principle of Removability".

Well I certainly agree with "The Principle of Removability" (who wouldn't?). However, there seems to be an implicit assumption that software is always in one of two states: "debugging/development" (where speed is not that important, and extra careful checking is needed) and "release" (where speed is very important, and extra careful checking would be wasted or even harmful). I find that for much of the software I write, that isn't an accurate model -- I need speed, but I don't want to forgo debuggability/checking in cases where the speed hit is not excessive. Because of this, I think it's useful to have more than just "all on" or "all off", because the cost of various debugging code varies a lot... Thanks, -Miles -- We have met the enemy, and he is us. -- Pogo

On Sep 20, 2007, at 5:40 AM, abhishek.v@tcs.com wrote:

How to find successor and predecessor of the vertex in BGL assume that we have specified the given the root vertex,,,, Is there any direct method to this..

The out_edges and in_edges functions, respectively, return iterators for the outgoing and incoming edges of a vertex. You can then extract the target or source of the edge (with the "target" and "source" functions) to determine the successors and predecessors. - Doug