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

Bug in serialization/weak_ptr.hpp in Boost 1.34.0 RC2
by Mikko Vainio 10 May '07

10 May '07

Is it too late to get this fixed before 1.34.0 ships? /Mikko Mikko Vainio wrote: > Could someone fix line 31 in serialization/weak_ptr.hpp to say > const boost::shared_ptr<T> sp = t.lock(); > as it does in the HEAD version. > > The line is now > const boost::shared_ptr<T> sp(t); > which will cause assertion failure with empty weak_ptr. Being empty is a > perfectly valid state for a weak_ptr, and should be serializable. > > Cheers, > Mikko

1 0

[threads] singletons
by james.jones＠firstinvestors.com 10 May '07

10 May '07

Interesting Dr. Dobbs article this month about threadsafe singletons... http://www.ddj.com/dept/cpp/199203083?pgno=1 Boost.Threads is mentioned as having an inefficient solution to the problem of once-called routines in Windows. Is it possible that the technique describe in this article could replace this implementation? - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

3 2

[pool] future directions
by Michael Gopshtein 10 May '07

10 May '07

According to documentation to "Pool" library, it is intended to be used "when there is a lot of allocation and deallocation of small objects". In our product we also use such pool for allocation of "normal" - heavier objects. In such case we can't benefit from significant improvement in memory consumption per object (overhead of malloc's internal structure relative to used size of the object), but the allocations themselves are much more efficient. Additional advantage is memory fragmentation - all objects in the pool reside in continuous memory blocks. The main problem with such usage is, in our case, that the pool never "returns" memory to the system, unless it's released. For example, if I use the pool for allocation of Event objects, and at some point of time I had 10000 concurrent events, the pool will occupy all that memory while the process is alive, even if for most of the time I use a small portion of it. As a solution I was thinking about adding a "defragment" function to memory pool, which will compact it by moving live objects to free cells at the "beginning" of the pool. Such feature can be implemented with help of additional "index" table of pointers. Of cause, instead of returning pointer to allocated object, the pool will return a wrapper object, actually pointing to that index table (for which separate "classical" pool can be used). So, the first question is: do you think such feature will be helpful? If yes - please share your thoughts regarding suggested and/or other implementations? Michael

5 9

[review] Boost.Guid
by Dave Jenkins 09 May '07

09 May '07

Overall, I think there is a need for this library and it works as described, so it should be Accepted. However, I have a serious concern with the performance when generating large numbers of GUIDs (see below). If not addressed, this might cause people to choose faster solutions over this library. - What is your evaluation of the design? I think the design is reasonable and complete enough for my use. I agree with a previous comment that UUID would be a better name for the library. - What is your evaluation of the implementation? I am concerned about the performance of this library when generating a large number of GUIDs. I wrote two small programs to compare performance between MSVC 8.0 native mode using the Boost.GUID library and C++.CLR using the Microsoft System.Guid library. The CLR version ran much faster. For ten million GUIDs, the times were 5 seconds for System.Guid, 16 seconds for Boost.GUID (random number based) and 12 seconds for Boost.Guid (name-based). The source code for the programs is attached. I would have expected the native mode program to run faster or about the same. Is there something wrong with my code? Could this be caused by the Thread lock? Or maybe the random number generator takes more time? - What is your evaluation of the documentation? At the start of the document, I would prefer a text paragraph or two describing what a GUID is, what they look like, and what the library does with them (input/output/create). Also, a description of the name-based and random-number-based alternatives might help up front. In the Design Notes section, could you provide a link to a SHA-1 reference like http://www.itl.nist.gov/fipspubs/fip180-1.htm. - What is your evaluation of the potential usefulness of the library? I think this is a useful library for many purposes. With multi-threading and multi-processor architectures becoming more popular, UUIDs will be used more frequently. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I tried a minimal example to test the performance using the MSVC 8.0 compiler. See my performance concerns above. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Moderate. I read the documentation and skimmed through the source code. - Are you knowledgeable about the problem domain? I have used UUIDs in the past and know, in theory, how they are generated. But I have always used databases, libraries, or utility programs to generate them. Regards, Dave Jenkins

2 1

[jam] "don't know how to make trie.c"
by Jonathan Wakely 09 May '07

09 May '07

I've just tried to run the Boost regressions tests for the first time in many months, and it failed when trying to build jam. ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= don't know how to make trie.c ...found 47 targets... ...can't find 1 target... ...can't make 1 target... ...skipped bjam for lack of trie.c... ...skipped 1 target... bjam build failed. Rene, did you forget to "cvs add trie.c" ? More generally, since I haven't done this in a while ... Can I still run tools/regression/run_tests.sh to run the tests for a number of toolsets? And should toolsets I've defined myself in $BOOST_BUILD_PATH still be found? Thanks, Jon

2 5

[boostcon] any bloggers attending?
by "JOAQUIN LOPEZ MU?Z" 09 May '07

09 May '07

Does anyone attending BoostCon have plans to blog about her experience during those days? It'd be a consolation for those of use who'd want to be there but can't for various reasons. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

Re: [boost] [Boost-announce] [SPAM:## 74%] [Review] The review of the Boost.Guid library starts today (April 30th)
by Tim Blechmann 09 May '07

09 May '07

hi all, first i need to say, i have been using the guid library in my computer music system 'nova' for quite some time now, and several core parts heavily rely on it. > - What is your evaluation of the design? the guid class is very easy to use and provides everything, that i needed for my application ... the only problems that i see, is the blocking implementation of guid::create() in order to use it in largely multithreaded environments, i would like to see an implementation with thread-local storage for the random number generator instead of a single one, guarded by a mutex... > - What is your evaluation of the implementation? from my point of view, it looks quite well-written. as it's a header-only library, it's very straight-forward to use ... > - What is your evaluation of the potential usefulness of the library? when looking for a uuid implementation, i didn't find another implementation, that's that portable to other platforms ... > - Did you try to use the library? With what compiler? Did you have any > problems? as stated above, i've been using the library for quite some time now. it's successfully running under gcc-4.0 on osx and >=gcc-4.1 on linux. however, i'm not sure about the naming of the library, whether it should be called 'uuid' or 'guid'. afaik 'guid' is the term used for the m$ implementation of the uuid iso standard, which is the reason, why i would be in favor of the term 'uuid' i would like to see the guid libary as part of boost. nevertheless, i'll continue to use the guid class, whether it is part of boost or not. cheers, tim -- tim(a)klingt.org ICQ: 96771783 http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

3 2

[Boost-bugs] [ boost-Patches-1715942 ] [bind] inline placeholder macro
by SourceForge.net 09 May '07

09 May '07

Patches item #1715942, was opened at 2007-05-09 13:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1715942&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: Daniel Walker (daniel_walker) Assigned to: Nobody/Anonymous (nobody) Summary: [bind] inline placeholder macro Initial Comment: This patch introduces and documents a macro to enable placeholders implemented as inline functions instead of static objects for compilers other than borland and g++ <= 4.0. Also, it gives g++ > 4.0 static object placeholders by default. This is important for the TR1 CopyConstructible requirement and for practical reasons when implementing operator overloads for placeholders. Finally, the patch also introduces a macro containing gcc's complete version number for convenient use with BOOST_WORKAROUND. See mailing list thread archived at http://tinyurl.com/yqvp8y. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1715942&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [1.34] [showstopper] autolink doesn't work when not specifyingtoolset version
by Thomas Witt 09 May '07

09 May '07

Hi, If this is a showstopper we better figure out what we do about it. My question is who is doing what and when? Any help with this issue will be greatly appreciated. Thanks Thomas On May 7, 2007, at 12:37 PM, David Abrahams wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.lib.boost.user as well. > > > on Sun May 06 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote: > >> I don't think there's anything that autolinking can do to fix this: >> it requires that libraries are named consistently, and there's no >> way around that. > > Yes, that's not what I meant to imply. > >> So we either need to update the docs, or preferably fix >> Boost.Build to >> detect the MSVC version. As Dave says it does this in other contexts >> already, so it should be possible. > > Exactly. > >> BTW, this is a showstopper for 1.34 release I believe. > > Absolutely. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > Don't Miss BoostCon 2007! ==> http://www.boostcon.com -- Thomas Witt witt(a)acm.org

5 11

boost development process / scope
by Stefan Seefeld 09 May '07

09 May '07

Here is a point I'd like to bring up in the context of the current discussion concerning the boost development process. I expect this issue to be highly controversial, hopefully it will result in a constructive discussion nonetheless... Boost is all about modern C++ libraries. However, in the (very admirable) drive for perfection, developers not only strive for the ultimate C++ libraries, but also for perfect development tools. Thus, an integral part of boost is * a build tool / infrastructure * a documentation harness * a testing harness This, IMO, creates a number of problems : * it heightens the barrier of entry for users as well as contributors, as they need to learn new languages and new tools (which, in general, are really understood only by a handful of people) * it creates considerable instability, as these tools have their own development lifecycle. (I remember someone mentioning that his documentation in the 1.34 branch depends on features of quickbook in trunk, etc.) * it dilutes the focus of boost itself So, in the spirit of 'lessons learned', I'd like to invite readers to imagine how life would be if the boost development would use existing (i.e. external) tools, if possible. (Example: docbook, rst, etc., instead of qbk; make instead of bjam, etc.) Please don't get me wrong: I'm not criticising any of these tools per se. They may be wonderful, and have clear advantages over external tools. But please don't underestimate the advantage taken from a great user base, or the experience that went into all these tools over the years. At least, I'd like to suggest that the development of these tools should be decoupled as much as possible from the development of the 'boost C++ libraries'. That should benefit everybody: The boost development would draw on a much more stable development environment, and these tools would hopefully be recognized in domains outside of boost, helping them to evolve and stabilize quicker than if the only deployment was inside boost. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

13 25