August 2005 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1256121 ] 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1256121, was opened at 2005-08-10 12:29 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=1256121&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC Initial Comment: Hello. My name is John Daub, email: hsoi(a)hsoi.com. I am using CodeWarrior Pro 9.5 on a dual G5/2GHz PowerMac (PPC). I believe the version of boost that I am using is 1.33 R1 as version.hpp says 1.33 and since 1.33 R2 was released only 2 days ago, I figure I must be using R1 (I didn't put boost into our CVS repository... someone else did that so I can't say what version of boost I have any more than that). However, I did check the 1.33 R2 and it seems to have the same problem. Going back to 1.32 however, I do not have the problem. It appears to be something introduced in 1.33. The problem stems from my use of the boost::shared_ptr class, and then ultimately how shared_ptr uses sp_counted_base to track the useCount. It seems boost 1.33 has introduced compiler and processor specific implementations of sp_counted_base. In the CodeWarrior PPC version (boost/detail/ sp_counted_base_cw_ppc.hpp) there are 3 inline functions: atomic_increment, atomic_decrement, atomic_conditional_increment. These 3 inline functions use inline assembly to do their work. That's fine. However, if you set the CW compiler to build with "don't inline", things work out fine. You can run and play and no problems. If however you set the CW compiler to "smart" inlining, then you will crash because these atomic functions don't work for some reason. FWIW, the other inlining options are set as follows: auto-inline is off, deferred inling is off, bottom-up inlining is on. You should be able to reproduce this yourself. I used my CW Pro 9.5 install and created a new project based upon the Mac OS C++ Stationery (the Mac OS Carbon, Standard Console, C++ Console Carbon, stationery). I added an access path to my boost library folder, and I added your own test file from boost-distro/libs/ smart_ptr/shared_ptr_test.cpp to the project. I changed nothing else about the project... just stock CodeWarrior stationery. If you ensure inlining is set to "don't inline", build, and it runs fine. If you then go back, change the setting to "smart" inlining, rebuild, and then run, you should see the console window comes up, some stuff appears in the window but quickly things crash. The problem is the useCount doesn't seem to increment, so when it later decrements, the count is off and things go wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256121&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

1 0

Improved boost::any
by christopher diggins 10 Aug '05

10 Aug '05

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

7 14

[Boost-bugs] [ boost-Bugs-1256069 ] 1.32.0 signals and shared_ptr mem-leak bug
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1256069, was opened at 2005-08-10 11:07 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=1256069&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: 1.32.0 signals and shared_ptr mem-leak bug Initial Comment: The attached file shows a discrepancy with boost 1.31 and 1.32 when dealing with shared_ptr's and signals. The 1.32 behavior can cause memory leaks in certain conditions. camior(a)gmail.com David J. Sankel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256069&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

1 0

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