- Boost - lists.boost.org

Re: [boost] New boost webpage
by Martin Bonner 10 Aug '05

10 Aug '05

----Original Message---- From: Beth Jacobson [mailto:bethj@bajac.com] Sent: 08 August 2005 21:27 To: boost(a)lists.boost.org Subject: Re: [boost] New boost webpage > Rob Stewart wrote: >> From: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> >> >>> They are blending with the text now, which is IMO a step back. >> >> >> They are more readable, however, and I find them sufficiently >> distinguished from the surrounding text. > > I just changed the link colors to their websafe versions. I can't see > any difference on my browser, but it may make things more consistent > across different browsers/OS's. It could be that you've been seeing > different colors. Hopefully this will fix that. I've just checked the site. I cannot see any difference between visited and unvisited links now (unless visited links are supposed to be paler). Can't we have a change of hue as well as lightness/saturation? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

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

10 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-10T15:06:17Z 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

[Boost-bugs] [ boost-Bugs-1255637 ] 1.33RC2: archive_pointer_[o/i]serializer assert problem
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1255637, was opened at 2005-08-10 02:36 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=1255637&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.33RC2: archive_pointer_[o/i]serializer assert problem Initial Comment: Hello again, FYI .. i read the boost mailing list, so posting anwers there is ok for me ;-) I made some progress after reading "rationale" though some things still give headaches. I have polymorphic class hierarchy which gets serialized thru base ptrs (along with shared_ptr stuff). When using portable_binary_oarchive/iarchive (taken from boost example) an assert() triggers which raises some questions. oserializer.hpp: -------------- snip -------------- // sice true_type is valid, and this only gets made if the // pointer oserializer object has been created, this should never fail bpos_ptr = archive_pointer_oserializer<Archive>::find(* true_type); assert(NULL != bpos_ptr); if(NULL == bpos_ptr) boost::throw_exception( archive_exception(archive_exception::unregistered_class) ); -------------- snip -------------- "should never fail" seems to fail and i dont know why ;-( (long callstack omitted) > test_protocollayers.exe!boost::archive::detail::save_pointer_type<portable_binary_oarchive,xxx::ProtocolHeader const *>::polymorphic<xxx::ProtocolHeader>::save(portable_binary_oarchive & ar={...}, const xxx::ProtocolHeader & t={...}, const boost::archive::detail::basic_pointer_oserializer * bpos_ptr=0x00000000) Line 416 C++ test_protocollayers.exe!boost::archive::detail::save_pointer_type<portable_binary_oarchive,xxx::ProtocolHeader const *>::save<xxx::ProtocolHeader>(portable_binary_oarchive & ar={...}, const xxx::ProtocolHeader & t={...}, const boost::archive::detail::basic_pointer_oserializer * bpos_ptr=0x00000000) Line 438 + 0x11 C++ test_protocollayers.exe!boost::archive::detail::save_pointer_type<portable_binary_oarchive,xxx::ProtocolHeader const *>::invoke(portable_binary_oarchive & ar={...}, const xxx::ProtocolHeader * const t=0x00680698) Line 466 + 0x11 C++ test_protocollayers.exe!boost::archive::save<portable_binary_oarchive,xxx::ProtocolHeader const *>(portable_binary_oarchive & ar={...}, const xxx::ProtocolHeader * const & t=0x00680698) Line 535 + 0xf C++ The classes usually contain: "template<class Archive> void serialize( Archive & ar, const unsigned int /* version */)" stuff, along with explicit: "boost::serialization::void_cast_register<Derived, Base>(0,0);" in ctors (or it doesnt work). "this_type" = abstract base "true_type" = derived both classes are successfully retrieved via type info (registered class). The "vp = serialization::void_downcast(*true_type, *this_type, &t);" works too (because the void_cast_register). But it doesnt find appropriate basic_pointer_oserializer .... I placed a breakpoint at "basic_serializer_map::insert(const basic_serializer * bs)" to see what types get registered at startup (initterm ctors). There are indeed registrations but some (derived) types are missing. What gives? BTW ... could you make "portable_binary_oarchive" (and iarchive) included in available boost archive types? I find it useful because serialization is used in cross platform protocol stacks (little vs. big endian archs). Is there any chance to reduce binary overhead due to registration data (shared_ptr/type info ... binary size almost doubled due to contained type info in small payloads). Can stringified type info be omitted/shortened (i use hierachial namespaces which blow the length)? Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1255637&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

2 1

[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