- Boost - lists.boost.org

Can't build boost 1.48 with STLport 5.2.1
by Robert Dailey 17 Feb '12

17 Feb '12

I'm trying to get Boost 1.48 building using STLport 5.2.1. I am on Windows 7 x64. Here is what I've done: 1. Update tools/build/v2/user-config.jam with the following: using msvc : 7.1 ; using stlport : 5.2.1 : C:/Code/third_party_source/STLport-5.2.1/stlport : C:/Code/third_party_source/STLport-5.2.1/lib ; 2. Run the following command through the VS2003 command line tool: bootstrap.bat 3. This sets up the b2 executable and stuff, after that I run: b2 toolset=msvc link=shared threading=multi runtime-link=shared variant=debug stdlib=stlport --layout=tagged stage However, once it comes time to link the first library (boost filesystem), I get a ton of linker errors, mostly LNK2001 relating to unresolved STLport symbols. Here is one of the first ones: path.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall stlpd _std::basic_string<wchar_t,class stlpd_std::char_traits<wchar_t>,class stlpd_std::allocator<wchar_t> >::basic_string<wchar_t,class stlpd_std::char_traits<wchar_t>,class stlpd_std::allocator<wchar_t> > (class stlpd_std::basic_string<wchar_t,class stlpd_std::char_traits<wchar_t>,class stlpd_std::alloca tor<wchar_t> > const &)" (__imp_??0?$basic_string@_WV?$char_traits@ _W@stlpd_std@@V?$allocator@_W@2@@ stlpd_std@@QAE@ABV01@@Z) Anyone have any idea how I can get this working? --------- Robert Dailey

4 19

Boost.Asio documentation needs to be updated
by Bernd Prager 17 Feb '12

17 Feb '12

All, The documentation states that Boost.Asio requires __USE_W32_SOCKETS must be defined when using Cygwin. That doesn't seem to be true any longer. When I define __USE_W32_SOCKETS compilation of several components (e.g. ./boost/test/impl/debug.ipp) fail with "error: '::select' has not been declared". Without that definition compilation works apparently fine. Regards, -- Bernd

1 0

[Block Pointer] Questions?
by Phil Bouchard 17 Feb '12

17 Feb '12

Hi, I was wondering if anybody had any question regarding Block Pointer. It might be hard to convince Java and C# authors garbage collectors are nonsense but we do not have that burden here. Thank you, -Phil Author of "Finite Theory of the Universe, Dark Matter Disproof and Faster-Than-Light Speed": http://bookstore.authorhouse.com/Products/SKU-000539350/Finite-Theory-of-th…

1 0

[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