February 2007 - Boost - lists.preview.boost.org

[date_time] time_zone_base.hpp should #include <sstream>
by Boris Gubenko 23 Feb '07

23 Feb '07

boost/date_time/time_zone_base.hpp uses std::basic_ostringstream without including standard library header <sstream>. Because of the missing header, date_time library test testlocal_time fails to compile on HP-UX/ia64 which uses Rogue Wave library 2.2. Can '#include <sstream>' be added to time_zone_base.hpp, in both 1.34 and HEAD? If not, can date_time library test testlocal_time be marked expected failure on HP-UX/ia64 (toolset "acc") ? Thanks, Boris

3 3

[bimap] Compiling Bimap
by John Maddock 23 Feb '07

23 Feb '07

I've started working through bimap in preparation for a review, but I'm having a few problems with the source: Gcc on linux, passes all the tests (tried AMD64 and IA64), good :-) Intel 9.1 on Linux, and HP aCC on HP-UX fails to build quite a few tests. These compilers are both based on a recent release of the highly regarded EDG front-end, and may indicate issues with the source. The HP aCC test run produced a 17Mb log file of errors and warnings (!) which is um, rather alarming so I'll contact Matias by private email with the logs. On Win32, everything builds with msvc, but I'm seeing access violations in: test_bimap_assign test_bimap_property_map with all of VC7.1, VC8, Intel 8.1 and 9.1. There are a few warnings as well that look suspicious to me: c:\data\boost\develop\boost\boost\multi_index\detail\ord_index_node.hpp(127) : warning C4312: 'type cast' : conversion from 'boost::multi_index::detail::uintptr_type' to 'void *' of greater size c:\data\boost\develop\boost\boost\multi_index\detail\ord_index_node.hpp(132) : warning C4311: 'type cast' : pointer truncation from 'void *' to 'boost::multi_index::detail::uintptr_type' c:\data\boost\develop\boost\boost\multi_index\detail\ord_index_node.hpp(159) : warning C4312: 'type cast' : conversion from 'const boost::multi_index::detail::uintptr_type' to 'void *' of greater size And finally, the serialization test fails to build with VC8 with: c:\data\boost\bimap\libs\bimap\test\test_bimap_serialization.cpp(53) : error C2872: 'bimap' : ambiguous symbol could be 'c:\data\boost\bimap\boost\bimap\bimap.hpp(149) : boost::bimap::bimap' or 'boost::bimap' c:\data\boost\bimap\libs\bimap\test\test_bimap_serialization.cpp(53) : error C2872: 'bimap' : ambiguous symbol could be 'c:\data\boost\bimap\boost\bimap\bimap.hpp(149) : boost::bimap::bimap' or 'boost::bimap' I note from the docs that these compilers are all listed as supported, so I'm guessing that either recent changes to Bimap, or to Boost cvs have broken something. Anyway I thought I'd bring these up in the hopes that there are some easy fixes, before other reviewers hit the same issues. I'll get back to reading the docs now :-) Regards, John.

3 8

boost.bimap example
by Jose 23 Feb '07

23 Feb '07

Hi, Boost.Bimap provides a simple translation example and I was wondering whether the library can be used for the general case of many to many relationships, i.e. Hola --< Hello Hola --< Hi Interesante >-- Cool Frio >-- Cool so that I basically can have two multimaps coupled together rather than having to build them separately Thanks and regards jose

2 1

[Boost-bugs] [ boost-Feature Requests-1666951 ] reset() for intrusive_ptr
by SourceForge.net 23 Feb '07

23 Feb '07

Feature Requests item #1666951, was opened at 2007-02-23 02:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1666951&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: reset() for intrusive_ptr Initial Comment: I would like to see intrusive_ptr<T>::reset() to release the contained pointer (if any), and set it to zero, i.e. with same effect (at least I *think* it should the same effect ;)) as operator=(intrusive_ptr<T>()) Reason: interface consistency with shared_ptr, scoped_ptr Or is there any reason for not having it? peterchen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1666951&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [serialization] performance comparison"
by brass goowy 23 Feb '07

23 Feb '07

>> There isn't a library to download. Its an online service. > >Ah OK, that makes it a useless in real world apps then for me and >probably a lot of other people. Do you think online code generation is useless in general? >From the docs it looks like you only >support some predefined types as well. We support user defined types, but there are limitations in this area. We're working on removing the limitations. >It would be more useful if you >publish the exact performance tests (and build files) you use so we can >make meaningful comparisions and know we're testing the same thing. Right. In doing this I found an error in what I reported about the sizes of the executables. I said that the Boost 1.35 version on Linux was about ~22,000 bytes and the EE version ~8,200 bytes. I had an include of an .ipp file in the boost version that wasn't needed. (It was needed on Windows.) When I removed that the Boost version was ~16,800 bytes. The run time numbers didn't change after removing the include. Sorry about the incorrect report. The Boost version of the test is here http://www.webEbenezer.net/bser.cc The EE version http://www.webEbenezer.net/ee.cc http://www.webEbenezer.net/msgs.h God is our refuge and strength, a very present help in trouble. Psalm 46:1 Brian Wood _______________________________________

3 2

Config macro to check for RTTI.
by Michael Marcin 23 Feb '07

23 Feb '07

Hi, I'm working on a platform that has exceptions and STL but no std::type_info (weird right?). I want to use lexical_cast but I can't only because bad_lexical_cast uses type_info. I've modified my local copy with #ifdef HAS_RTTI around the 3 places bad_lexical_cast is used to simply throw a bad_lexical_cast without the source and target type_info members. Is there a standard BOOST_HAS_TYPE_INFO or some other config macro I can/should use for this? Thanks, Michael Marcin

2 1

BoostCon 2007
by Terence Wilson 23 Feb '07

23 Feb '07

The web page hasn't changed for some time. Is this still planned? When will registration open? Terence Wilson

2 1

Bimap
by Christian Henning 22 Feb '07

22 Feb '07

Hi guys, I'm sorry I haven't quite followed the current discussion until I saw a use case that I would like to add to my application. So I started by trying to compile the mighty bimap example and it failed. Are there any problems with the MSVC 7.1 compiler? Or do I need to have the latest CVS head of the needed boost libs? Anyway here is the first the error: error C2661: 'boost::bimap::container_adaptor::sequence_container_adaptor<Base,Iterator,ConstIterator,ReverseIterator,ConstReverseIterator,IteratorToBaseConverter,IteratorFromBaseConverter,ReverseIteratorFromBaseConverter,ValueToBaseConverter,ValueFromBaseConverter,FunctorsFromDerivedClasses>::insert' : no overloaded function takes 1 arguments it happens in the code line: translator.insert( translation("hola" ,"hello" ) ); Christian

2 2

[Review][Bimap] Bimap review extended until March 2nd
by Ion Gaztañaga 22 Feb '07

22 Feb '07

Hi to all, Bimap review has been extended until March 2nd. I encourage all boosters to give a try to this great library. The links are: Start reading the documentation here: http://tinyurl.com/y95qng And download the library here: http://boost-consulting.com/vault/index.php?&directory=Containers Regards, Ion

1 0

[Boost.Graph] specifying PropertyGraphConcept requirements
by Brook Milligan 22 Feb '07

22 Feb '07

I am trying to specify the requirement that types cover the PropertyGraphConcept of the BGL. The following code illustrates a simple test case. #include <boost/graph/adjacency_list.hpp> struct VertexProperties { typedef VertexProperties kind; int distance; }; struct EdgeProperties { typedef EdgeProperties kind; int weight; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProperties, EdgeProperties> graph_type; int main() { boost::function_requires< boost::PropertyGraphConcept<graph_type, int, int VertexProperties::*> >(); return 0; } However, with Boost v1.33.1, the concept check yields the following error: /usr/pkg/include/boost/property_map.hpp:158: error: assignment of read-only data-member ` boost::ReadablePropertyMapConcept<boost::bundle_property_map<const graph_type, size_t, VertexProperties, const int>, int>::val' The location of that error is associated with the indicated line clipped out of property_map.hpp: // property_map.hpp template <class PMap, class Key> struct ReadablePropertyMapConcept { typedef typename property_traits<PMap>::key_type key_type; typedef typename property_traits<PMap>::reference reference; typedef typename property_traits<PMap>::category Category; typedef boost::readable_property_map_tag ReadableTag; void constraints() { function_requires< ConvertibleConcept<Category, ReadableTag> >(); val = get(pmap, k); // <== read-only assignment error } PMap pmap; Key k; typename property_traits<PMap>::value_type val; }; Perhaps the template arguments in the concept checking are wrong; I have found the documentation unclear on how to really use these. Any help on how to make this work correctly is greatly appreciated. Thanks alot. Cheers, Brook

1 0