- Boost - lists.boost.org

[exception] warning about non-virtual destructor - resolution?
by Nathan Ridge 16 Feb '12

16 Feb '12

Hello, GCC 4.7 introduces a new warning [1] that warns about calling "delete" on a pointer of a type that has virtual functions but a nonvirtual destructor. This warning is enabled with -Wall. As a result, even something as trivial as the following: #include <boost/thread/future.hpp> when compiled with -Wall, produces a warning like this: In file included from boost/boost/smart_ptr/shared_ptr.hpp:30:0, from boost/boost/shared_ptr.hpp:17, from boost/boost/date_time/time_clock.hpp:17, from boost/boost/thread/thread_time.hpp:9, from boost/boost/thread/future.hpp:13, from Source/timetable.cpp:1: boost/boost/checked_delete.hpp: In instantiation of 'void boost::checked_delete(T*) [with T = boost::error_info<boost::tag_original_exception_type, const std::type_info*>]': boost/boost/smart_ptr/detail/shared_count.hpp:95:13: required from 'boost::detail::shared_count::shared_count(Y*) [with Y = boost::error_info<boost::tag_original_exception_type, const std::type_info*>]' boost/boost/smart_ptr/shared_ptr.hpp:177:50: required from 'boost::shared_ptr<T>::shared_ptr(Y*) [with Y = boost::error_info<boost::tag_original_exception_type, const std::type_info*>; T = boost::error_info<boost::tag_original_exception_type, const std::type_info*>]' boost/boost/exception/info.hpp:171:69: required from 'const E& boost::exception_detail::set_info(const E&, const boost::error_info<Tag, T>&) [with E = boost::unknown_exception; Tag = boost::tag_original_exception_type; T = const std::type_info*]' boost/boost/exception/info.hpp:192:46: required from 'typename boost::enable_if<boost::exception_detail::derives_boost_exception<E>, const E&>::type boost::operator<<(const E&, const boost::error_info<Tag, T>&) [with E = boost::unknown_exception; Tag = boost::tag_original_exception_type; T = const std::type_info*; typename boost::enable_if<boost::exception_detail::derives_boost_exception<E>, const E&>::type = const boost::unknown_exception&]' boost/boost/exception/detail/exception_ptr.hpp:182:13: required from 'void boost::unknown_exception::add_original_type(const E&) [with E = std::exception]' boost/boost/exception/detail/exception_ptr.hpp:161:32: required from here boost/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Note that the same code compiled without warnings with GCC 4.6. I've read this thread [2] about this issue, but it's not clear what the agreed-upon resolution was. In light of this new warning, can the code be revised to avoid it? Or is it the position of the library maintainers that GCC is in error to give a warning in this case, in which case I should file a GCC bug? Or is there some other recommended resolution? Thanks, Nate [1] http://gcc.gnu.org/gcc-4.7/changes.html#cxx [2] http://boost.2283326.n4.nabble.com/boost-exception-detail-error-info-base-d…

2 2

fix links in boost.container docs
by niXman 16 Feb '12

16 Feb '12

Hello list! Diff file is attached. niXman.

1 0

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 16 Feb '12

16 Feb '12

> > FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation. > > Could you give a use case for optional<T&>. When reading the doc about I completely understand the other use cases: > * return types > * parameters > * locals > * members > * expensive unnecessary default construction > We could be having the same conversation about optional<bool>. Here the documentation is clear: it works as expected but is the user probably should be using tri-state. > We could optimize optional<bool> to store ~0 to indicate unset. I personally don't think it's worth doing that, since use case is questionable. > As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*. It also allows for debates about the meaning of reassignment. > I'm not dead set against this optimization. I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests. Speaking for myself, I do not have a need for optional reference. I have been using Boost.Optional for many years, I find it extremely useful; and I never had a use case for optional reference. On the other hand, others seem to be in need of optional references.Andrey said in this thread that that he wants to use it. The only two motivating use cases that triggered the addition of optional references (that I am aware of) is the interface of Boost.Variant (see http://lists.boost.org/Archives/boost/2003/02/44585.php) and the use case for Boost.Spirit (see http://lists.boost.org/Archives/boost/2003/10/55584.php) I would be reluctant to just discard these use cases. On the other hand, if they are allowed, the controversy of assignment arises. One thing to note is the requirement for optional references is not motivated by optimization opportunities, but additional behavior. > Side question: is streamablity going to be in your proposal? It is not currently. The reason for that is that there is no clear way how it should be implemented (a similar issue applies to pairs, tuples, variant, any, etc...) See http://lists.boost.org/Archives/boost/2005/03/81619.php for discussion. I believe that the problem is with the streaming itself. For instance, should streaming out and then streaming the result back in produce the same value? Some people expect that, but even std::string could not provide this behavior. Regards, &rzej

12 20

Boost Graph Library - serialization of subgraph
by Ernest Galbrun 16 Feb '12

16 Feb '12

Dear fellow boost member, I am currently using the boost graph library, and especially the subgraph features. As there is no serialization feature for subgraphes, I have developped my own, by modifying the one developed by Rakuto that was broken, probably due to some changes in the graph library ( http://rakuto.blogspot.com/2008/12/c-library-for-serialazation-of.html ). If you think it would be useful, I could do the remaining work (that is thorough testing and debugging, and providing automated test case, maybe I am forgetting something ?). The bottom line is that I am new to this kind of project, and I will probably need some kind of guidance about the way to contribute. sincerely yours, -- Ernest Galbrun

1 0

how to search this list efficiently ?
by Steven Samuel Cole 16 Feb '12

16 Feb '12

i have a few questions about boost that might have been discussed and answered on this list before. there seems a convention to add the topic in square brackets to the subject as e.g. [thread], [preprocessor] or [review], etc. how do i search the list archive by these topics ? i see there is http://search.gmane.org/ but that only supports search by keywords in the entire message and seems to ignore [square brackets]. there is also custom google search on the boost homepage which i can further filter down to the mailing lists by adding site:lists.boost.org, but it also ignores square brackets, even when put in double quotes and does not seem to allow sorting by date or support a threaded display. lists.boost.org/Archives/boost/ doesn't support searching at all. is there a trick how to search the mailing list archives properly ?

5 7

[intrusive] advanced lookup/insertion suggestion
by Rei Thiessen 16 Feb '12

16 Feb '12

Something that has bothered me with the advanced lookup and insertion functions is that I have to specify the hash/equality functors at every invocation site: c.find(key,key_hash(),key_equality()); c.insert_check(key,key_hash(),key_equality(),cd); If we don't consistently use the same (key_hash,key_equality) pair for a given (element_type,key_type) pair, the container invariant will likely be broken. Thus, I think it's very un-"C++ like" to have to specify these two types at every invocation site. Assuming that we don't want to embed (key_type,key_hash,key_equality) directly into the type of a container, the library could use a type operator to automatically deduce the appropriate hash/equality functions given an element/key type pair at the find/insert member function instantiation point: // library template<typename ElementType, typename KeyType> struct element_key_info {}; // different name to avoid overload confusion. // instantiation succeeds only when // element_key_info is properly specialized template<typename KeyType> iterator unordered_set::find_key( KeyType const& k ) {...} ... // user namespace intrusive{ template<> struct element_key_info<element_type,key_type> { typedef key_hash hash_type; typedef key_equality equality_type; }; } element_type e(...); c.insert( e ); key_type k(...); ... = c.find_key( k ); These new signatures do not allow non-default-constructible hash/equality functors, but the original signatures that do are still available. I think this makes the code simpler and safer in exchange for some additional type declarations. Would this be a worthwhile addition to the intrusive associative containers?

2 2

Offering sorted_vector for Boost, any interest?
by Frank Birbacher 15 Feb '12

15 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I've come across lots of code that uses std::set where I think a sorted vector would perform better. Those places a characterized by: 1. fills the set only once, 2. just wants to drop duplicates or 3. calls set::find very often. Facing such code I often wished there was a ready to use sorted_vector implementation. I think a new container that stores elements in a vector instead of a tree offers strong advantages: a. one call to std::sort instead of managing a red-black-tree b. less memory overhead c. better data locality for lookup Possible things that I currently consider: - - offer one-time initialization read-only sorted container? - - offer mutable container with std::set-like interface (complexity changes)? - - offer taking contents from std::vector for init without copying - - offer equivalent to std::map also? - - provide a pointer container, too? Is there general interest in such a container? I'd like to develop an implementation and offer it to Boost. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk87/wQACgkQhAOUmAZhnmqVdQCggs40nPsT7wXvoEuO3TsSWlqS Wt4An06uRHECRercybiKC0Jq/ZKobEsu =zAK6 -----END PGP SIGNATURE-----

7 14

Adding support for auto in Boost.Foreach
by paul Fultz 15 Feb '12

15 Feb '12

I have a macro that I use on older compiers that let's me use auto inside of a foreach loop using the typeof operator. My original implementation relies on variadiac macros, but it can be rewritten without requiring variadiac support(possibly using the new keyword facility from Lorenzo Caminiti). Here is examples of some foreach loops it would support: BOOST_FOREACH(auto x, range) {} BOOST_FOREACH(auto& x, range) {} BOOST_FOREACH(const auto& x, range) {} BOOST_FOREACH(volatile auto x, range) {} Also, on compilers that support variadiac macros, it would be nice to add support for commas in the type, such as: BOOST_FOREACH(pair<string, string> p, range) {} This would work by poping off the back of the sequence in order to get the container. Now, you could only have commas in the type and not the container, so this wouldn't work: //Won't work BOOST_FOREACH(auto x, get_some_range<A, B>()) {} However, 1) We can place parenthesis around the container, like this: BOOST_FOREACH(auto x, (get_some_range<A, B>())) {} 2) Almost 95% of the gotchas with the foreach seemed to be with using commas in the type. So ultimately, I think it would reduce the number of gotchas drastically. Is there interest in adding something like this? Or maybe just part of it? Also if there interest, what kind of process would I go through to get them submitted and reviewed? -paul

6 8

[trunk] test compilation fails on Cygwin
by Bernd Prager 15 Feb '12

15 Feb '12

I am getting following error with g++ (GCC) 4.5.3 on Cygwin 1.7.20: In file included from libs\test\src\debug.cpp:16:0: ./boost/test/impl/debug.ipp: In function ‘bool boost::debug::attach_debugger(bool)’: ./boost/test/impl/debug.ipp:899:9: error: ‘::select’ has not been declared

1 0

[Format] Making a change
by John M. Dlugosz 15 Feb '12

15 Feb '12

I'd like to make a change to the Boost Format library, to add a conversion operator to the matching string class. It appears to have not been worked on in a number of years. Reading through the web site, I find details on how to submit new libraries, and how to edit the web page, but nothing on submitting updates to existing libraries. How would I go about doing that, for this library in particular? —John

8 15