boost::ptr_vector null check bloat
I tried changing some of my code that used std::vector<foo *> to using boost::ptr_vector<foo> (to get automatic deallocation and the slightly nicer syntax), but the resulting compiled code seems oddly bloated compared to the original code using std::vector. My intuition is that the two should generally compile to largely equivalent object code, except where there's a necessary functional difference. Some of the problem seems to be that it does null-pointer checking at _access_ time, instead of when adding new entries. The result is that (for instance) calls to operator[] end up with an "unnecessary" null check, which drags in tons of stuff related to the accompanying assertion failure, some of which is apparently unshared across object files, like the long __PRETTY_FUNCTION__ strings passed to the assertion failure call. What's the general impression people have of boost::ptr_vector and related classes? Do people use it? Does it have a "bloat" reputation? Thanks, -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson
Miles Bader skrev:
Are you referring to a debug build? If so, why do you care about it? What compiler? 1.34 introduced a macro for tuning all the exceptions into asserts.
Does it have a "bloat" reputation?
Well, there has been some indications that the void* implementation leads to slightly slower code. OTOH, the void* implementation was made exactly to avoid bloat on compilers that generate new code for every T*. -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> 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
Miles Bader skrev:
See http://www.boost.org/libs/ptr_container/doc/reference.html#disabling-the-use... btw
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
Are asserts generally smaller/larger than throws?
At least when compiled away :-) -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> 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.
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<T,VoidPtrSeq>, 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<value_type>( 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
Miles Bader skrev:
Just about any boost library has the implicit assumption that assertions are compiled away *if the optimal efficiency/smallest code is to be gained*. PtrContainer additionally throws a few exceptions, but these can be disabled too. 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". cheers -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
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
Hi 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.. Thanks Abhishek Vyas Tata Consultancy Services Mailto: abhishek.v@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
On Sep 20, 2007, at 5:40 AM, abhishek.v@tcs.com wrote:
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
participants (4)
-
abhishek.v＠tcs.com -
Doug Gregor -
Miles Bader -
Thorsten Ottosen