- Boost - lists.boost.org

[serialization] two problems
by Vladimir Prus 10 Aug '05

10 Aug '05

Hi, after "cvs up" is run into two new problems with serialization. First is missing include, patch attached. The second is this: gcc.compile.c++ ../../../src/runtime/bin/gcc/debug/threading-multi/runtime_standalone.o In file included from /space/NM/boost/boost/archive/detail/iserializer.hpp:47, from /space/NM/boost/boost/archive/basic_binary_iarchive.hpp:36, from /space/NM/boost/boost/archive/binary_iarchive.hpp:21, from ../../../src/runtime/runtime_standalone.cpp:14: /space/NM/boost/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /space/NM/boost/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>' The second patch addresses this problem, but I'd also suggest to remove boost/serialization/is_abstract.hpp to avoid further problems. This happens in CVS HEAD, but I suspect the same problems might be present on release branch, and so should be merged there. - Volodya

2 5

[format] Inconsistency with printf
by martin.ecker＠tab.at 10 Aug '05

10 Aug '05

1 0

Re: [boost] alignment problem in proposed any alternative
by Martin Bonner 10 Aug '05

10 Aug '05

----Original Message---- From: christopher diggins [mailto:cdiggins@videotron.ca] Sent: 10 August 2005 06:30 To: Boost mailing list Subject: [boost] alignment problem in proposed any alternative > The question I have is whether in practice though are there are any > compilers which have stricter alignment requirements on small types > (<= sizeof(void*)) than a void pointer. I don't know of any such compilers, but I /can/ conceive of such. A (16-bit) word addressed machine where sizeof(int*) is 4 but sizeof(void*) is 6 might have the required alignment of int be 4, but the required alignment of void* only be 2 :-( On the other hand, it might be acceptable to say "boost::any" is not supported on such machines. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] Improved boost::any
by felipe 10 Aug '05

10 Aug '05

hello and good day to all, Well, I posted earlier about this, but yes, if you are going make a decent "any" with stack-allocation, you should let the maximum buffer size be variable. I didn't go into details about alignment or exceptions because I think it's pretty much old news. (In his article "Discriminated Unions", Andrei Alexandrescu considers all of this, however I don't totally agree with his implementation--too hairy for the 9-to-5 programmer.) My own recommendation is that both alignment and buffer size be adjustable. By default they should have sensible values. For example, 8 for both gives decent results on a lot of platforms, although you could do better with the help of sizeof and alignment_of. Besides simplifying the class definition, letting the programmer tweak alignment can be useful for types that can benefit from extra alignment. An example might be a character array--it only "needs" byte alignment, but maybe all of the string operations are tweaked for 32-bit alignment. Somebody made a rather interesting question, whether an object having size less than void * might need alignment greater than void *. Well, about the only maxim the C/C++ standards give is that alignment is platform dependent. In practice, I've never seen such a strange case. I think that sizeof(X) <= sizeof(Y) is a pretty good indicator that alignment(X) <= alignment(Y). (But remember, "minimum-acceptable" alignment is not the same as "optimum" alignment--my pentium lets me store and fetch a double at 0xDEADBEEF, but these operations aren't cheap!) Also, be careful with alignment_of: I remember it giving me some strange values on some illegal but idiomatic structures (e.g. zero-length arrays). If it gives you zero, put 8 or something you think is sensible. hope this helps On Tue, 09 Aug 2005 18:07:06 +0200, <boost-request(a)lists.boost.org> wrote: > Date: Tue, 09 Aug 2005 10:17:48 -0400 > From: christopher diggins <cdiggins(a)videotron.ca> > Subject: Re: [boost] Improved boost::any > To: boost(a)lists.boost.org > Message-ID: <026101c59ced$1ee4a3d0$2b792518@heronnest> > Content-Type: text/plain; format=flowed; charset=iso-8859-1; > reply-type=original > ----- Original Message ----- > From: "Vladimir Prus" <ghost(a)cs.msu.su> >> >> If the trick is to use "void*" pointer to data for storing data when >> it's >> small, then: >> >> - it's interesting to see performance comparison for any<string>, or >> any<some_other_large_class> > Another part of the optimization, is to avoid reallocating when > reassigning > any a different value with the same type. > On a related note: several people have suggested that a buffer should be > used with an arbitrary size set at compile time, which would help > significantly for container types. > >> - can't this be just patch to boost::any, as opposed to completely >> different >> class? > What does submitting a patch entail? Is that the way to go if the > implementation is completely different? > - Chriostopher Diggins -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0

[Boost-bugs] [ boost-Bugs-1254062 ] 1.33 RC2: polymorphic stuff broken further??
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1254062, was opened at 2005-08-08 03:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1254062&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: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: 1.33 RC2: polymorphic stuff broken further?? Initial Comment: Hello again, i just downloaded 1.33 RC2 and noticed polymorphic serialization doesnt work for my projects anymore. These errors are new and different from RC1 (which didnt work too, but 1.32 works). I cant get it compile anymore (static compile time asserts and others)... I even loaded up the provided sample boost ser. projects and notice there are similar errors too (from libs\serialization\vc7ide\*.sln) ---- demo_exception demo_exception.cpp e:\SDK\Boost\boost_1_33_0_RC2\libs\serialization\vc7ide\..\..\..\boost\archive\detail\oserializer.hpp(566) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] e:\SDK\Boost\boost_1_33_0_RC2\libs\serialization\vc7ide\..\..\..\boost\archive\detail\oserializer.hpp(566) : see reference to class template instantiation 'boost::STATIC_ASSERTION_FAILURE<x>' being compiled with [ x=false ] e:\SDK\Boost\boost_1_33_0_RC2\libs\serialization\vc7ide\..\..\..\boost\archive\basic_text_oarchive.hpp(78) : see reference to function template instantiation 'void boost::archive::save<Archive,T>(Archive &,T & )' being compiled with [ Archive=boost::archive::text_oarchive, T=School * ] e:\SDK\Boost\boost_1_33_0_RC2\libs\serialization\vc7ide\..\..\..\boost\archive\detail\interface_oarchive.hpp(85) : see reference to function template instantiation 'void boost::archive::basic_text_oarchive<Archive>::save_override<T>(T & ,int)' being compiled with [ Archive=boost::archive::text_oarchive, T=School * ] \SDK\Boost\boost_1_33_0_RC2\libs\serialization\example\demo_exception.cpp(219) : see reference to function template instantiation 'Archive &boost::archive::detail::interface_oarchive<Archive>::operator <<<School*>(T & )' being compiled with [ Archive=boost::archive::text_oarchive, T=School * ] (iserializer is same problem:) Boost\boost_1_33_0_RC2\libs\serialization\vc7ide\..\..\..\boost\archive\detail\iserializer.hpp(544) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' (similar to error in my projects) These errors go away if i make objects to be serialized "const" e.g. (for the sample) school* const .. ???? This "constness" constraint didnt show up in 1.32. It is especially difficult to enforce it if you serialize members with "ar & m1 & m2 .. " notation. ----- demo_shared_ptr: Boost\boost_1_33_0_RC2\libs\serialization\example\demo_shared_ptr.cpp(138) : error C2039: 'sp_counted_base_impl' : is not a member of 'boost::detail' Boost\boost_1_33_0_RC2\libs\serialization\example\demo_shared_ptr.cpp(138) : error C2061: syntax error : identifier 'sp_counted_base_impl' .... There are some errors with invalid project references and library names at all (linker errors, tries to link with wrong libs). It seems the project files are out of sync for long time. ---------------- Additionally: boost\boost\archive\detail\interface_iarchive.hpp(73) : error C2039: 'basic_iarchive' : is not a member of 'boost::archive::polymorphic_iarchive' boost\boost\archive\polymorphic_iarchive.hpp(52) : see declaration of 'boost::archive::polymorphic_iarchive' boost\boost\archive\detail\interface_iarchive.hpp(72) : while compiling class-template member function 'void boost::archive::detail::interface_iarchive<Archive>::lookup_helper(const boost::serialization::extended_type_info *const ,boost::shared_ptr<T> &)' boost\boost\archive\detail\interface_iarchive.hpp(73) : error C2662: 'boost::archive::detail::basic_iarchive::lookup_basic_helper' : cannot convert 'this' pointer from 'boost::archive::polymorphic_iarchive' to 'boost::archive::detail::basic_iarchive &' Reason: cannot convert from 'boost::archive::polymorphic_iarchive' to 'boost::archive::detail::basic_iarchive' Conversion requires a second user-defined-conversion operator or constructor This is my include list (i use precompiled header): ... #include "boost/archive/polymorphic_oarchive.hpp" #include "boost/archive/polymorphic_iarchive.hpp" #include "boost/serialization/shared_ptr.hpp" #include "boost/serialization/serialization.hpp" #include "boost/serialization/utility.hpp" #include "boost/serialization/list.hpp" #include "boost/serialization/version.hpp" #include "boost/serialization/map.hpp" #include "boost/serialization/vector.hpp" #include "boost/serialization/string.hpp" #include "boost/serialization/split_member.hpp" (i had to move "boost/serialization/shared_ptr.hpp" backwards after "archive" headers in contrast to 1.32) These 1.33 poly serialization bugs are big showstoppers for us because we extensively use serialization. If they remain, 1.33 will have to be skipped... Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1254062&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

3 4

Custom allocator for shared_ptr
by Dave 10 Aug '05

10 Aug '05

Hello all, I assume that the reference count object pointed to by shared_ptr objects is on the heap. Is there a way that I can specify a custom allocator for shared_ptr to use for this purpose? Thanks, Dave

4 3

[mpl] sort algorithm complexity
by Felipe Magno de Almeida 10 Aug '05

10 Aug '05

In the page it is informed that sort has an average complexity of O(nlog n), but I'm writing this: template <typename T, typename U> struct sort_hierarchy_pred : mpl::not_< boost::is_base_and_derived<T, U> >::type { }; typedef mpl::back_inserter< mpl::vector<> > aux_in; template <typename SequenceT> struct sort_hierarchies : public mpl::sort<SequenceT, typename mpl::lambda<sort_hierarchy_pred<mpl::_, mpl::_> >::type , aux_in> {}; and for a sequence of 5 or more, the compile time and memory usage gets too huge. To became unuseable. What I'm trying to achieve is a sequence of types that are sorted with the bases first... Could anybody shed some light why and if there's some workaround this? thanks in advance, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

3 10

Problem with writing a dijkstra_visitor
by Fabian Buske 09 Aug '05

09 Aug '05

Hi, I'm trying to write a dijkstra visitor, that sets the weight of an egde to the maximum value after assigning it to a minimum spanning tree. The visitor is created according to the bacon sample: template <typename WeightMap> class special_dijkstra_visitor : public boost::default_dijkstra_visitor { public: special_dijkstra_visitor(WeightMap& w):default_dijkstra_visitor(),weight_map_(w){}; template <typename Edge, typename Graph> void edge_relaxed(Edge e, Graph& g) { weight_map_[e] = DBL_MAX; } template <class Edge, class Graph> void edge_not_relaxed(Edge e, Graph& g) { weight_map_[e] = DBL_MAX; } private: WeightMap weight_map_; }; // Convenience function template <typename WeightMap> special_dijkstra_visitor<WeightMap> visit_special_dijkstra(WeightMap w) { return special_dijkstra_visitor<WeightMap>(w); } The graph based on an adjacency matrix with property<edge_weight_t, double> The visitor is called by: property_map<Graph, edge_weight_t>::type weightmap = get(edge_weight, g); prim_minimum_spanning_tree(g, root, &p[0], distance, weightmap, indexmap, visitor(visit_special_dijkstra(weightmap))); The linux gnu 3.4.4 compiler gives the following error messages *snip template instance error messages* /zeug/study/OpenMSLibs/CGAL-3.1-gcc-3.4.4/include/boost/graph/dijkstra_shortest_paths.hpp:120: error: ` edge_relaxed' undeclared (first use this function) /zeug/study/OpenMSLibs/CGAL-3.1-gcc-3.4.4/include/boost/graph/dijkstra_shortest_paths.hpp:122: error: ` edge_not_relaxed' undeclared (first use this function) /zeug/study/OpenMSLibs/CGAL-3.1-gcc-3.4.4/include/boost/graph/dijkstra_shortest_paths.hpp:143: error: ` finish_vertex' undeclared (first use this function) ... I'm wondering, cause I thought deriving from default_dijkstra_visitor ensures that finish_vertex is allready implemented. Compiling the bacon sample on the same graph works fine. So I'm really confused. Any hints for debugging the code? Thanks a lot. Regards Fabian

2 1

Boost regression notification (2005-08-09)
by Douglas Gregor 09 Aug '05

09 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-09T14:43:35Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

Re: [boost] Improved boost::any
by Eyal Farago 09 Aug '05

09 Aug '05

I read the code project article and I have few comments: 1. why optimize only for types smaller than void*? you can specify a different max size (bigger than sizeof(void*) and probably a product of it with another integer) to achieve even better results. 2. the implementation is pretty messy and quite dangerous, I'm quite sure it wouldn't compile/work on multimple platforms, and the first one that pops into my mind is solaris which enforce proper alighnment... 3. it is possible to borrow some of the tricks boost::variant uses to achieve correct allignment. i.e. using a boost::variant<void*, char[/*buffer size here*/]> and when the buffer is used store the actual alignment in a member variable of the class. 4. if 3 isn't possible, look at boost::function implementation, but I'm not sure if they're using a buffer or a simple union with a void* and few other types... eyal. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of christopher diggins Sent: Tuesday, August 09, 2005 12:49 AM To: Boost mailing list Subject: [boost] Improved boost::any I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest? Christopher Diggins http://www.cdiggins.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1