April 2009 - Boost - lists.preview.boost.org

[1.39.0][flyweight] Failing Mac OS test
by Beman Dawes 18 Apr '09

18 Apr '09

On the release branch, test_intermod_holder is failing for all Mac OS testers. See http://beta.boost.org/development/tests/release/developer/flyweight.html The error message is: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): File name too long Can we get this fixed for the release? If not, it needs to be marked up as an expected failure. Thanks, --Beman

3 4

The noexcept Specifier & Block
by Alexander Terekhov 18 Apr '09

18 Apr '09

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html#noexcept I gather that noexcept void f() { throw 0; } is supposed to be ill-formed versus well-formed noexcept void f() { noexcept { throw 0; } } invoking undefined behaviour. Well, this is not helpful. Both forms shall be well-formed with defined behaviour: invocation of unexpected() at throw point. regards, alexander.

7 29

RFC: serialization library in C only for C only
by Francis ANDRE 18 Apr '09

18 Apr '09

Hi Boosters Following a recommendation of Robert RAMEY about a serialization library similar to the Boost Serialization library but targeted only for the C language and using only the C language and/or some assembly routines, I am looking for any comments/advises on the feasibility of such library. The initial scope would be: 1/ Serialize/deserialize all primitive C types. 2/ Serialize/deserialize all constructed type like struct and union. 3/ Serialize/deserialize a tree/forest of C structures instances linked by pointers. What would be the charge/effort/workload of such library? Does anybody already try/succeed in building such library? Thank in advance for any comment. Francis ANDRE PS: Solving this issue by building a wrapper from C to the Boost Serialization library is not an option, hence this RFC.

2 2

[1.39.0][Interprocess] release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Interprocess has a few scattered failures. See http://beta.boost.org/development/tests/release/developer/interprocess.html Please fix or markup. Thanks, --Beman

3 3

[1.39.0][Interval] Release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Numeric/interval is failing three tests on some of the Mac OS platforms. See http://beta.boost.org/development/tests/release/developer/numeric-interval.… Please fix or markup. Thanks, --Beman

2 1

Boost.Conversion: request for interest
by vicente.botet 16 Apr '09

16 Apr '09

Hi, I've developed a utility library Boost.Conversion. I would like to know if the Boost community is interested in this library. If this is the case, this library could be scheduled for review quite soon. This library is related to LexicalCast, NumericConversion and (String)Convert, but much less specific. It provides a convert_to generic function (like swap) which can be specialized by the user to convert specific unrelated types, and why not, he could use one of the preceding libraries. This convert_to function can be seen as an extrinsec explicit conversion operator. The livrary provides also an assign_to generic function that can be seen as an extrinsec explicit assignement operator. Please let me know what do you think. What is wrong? What is missing? How can I improve it? Thanks, Vicente == Boost.Conversion == Links:http://www.boostpro.com/vault/index.php?action=downloadfile&filename=… Categories: Utilities Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic convert_to function which can be specialized by the user to make explicit conversion between unrelated types. * a generic assign_to function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between std::pair of explicitly convertible types. * conversion between boost::optional of explicitly convertible types. * conversion between boost::chrono::time_point and boost::ptime. * conversion between boost::chrono::duration and boost::time_duration. Soon conversion between std::vector, boost::array, and boost::tuple of explicitly convertible types. Motivation Imagine you need to convert unrelated types Source and Target. You can get it by defining a specific function such as Target SourceToTarget(Source& v); Imagine now that you need to convert a std::pair<Source, Source> to a std::pair<Target, Target>. Well you can again define a specific function std::pair<Target,Target> PairOfSourceToPairOfTarget(std::pair<Source,Source>& v) { return std::make_pair(SourceToTarget(v.fisrt), SourceToTarget(v.second)); } While the SourceToTarget could be specific, the PairOfSourceToPairOfTarget sould be generic template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v); In order to do that we need that the pair template parameters define a common function, let it call convert_to, template <typename Target, typename Source) Target convert_to(Source& v); so ConvertPair can be defined as template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v) { return std::make_pair(convert_to(v.fisrt), convert_to(v.second)); } The issue is that we need to specialize the convert_to function for the classes Source and Target. We can do it as follows template <> Target convert_to<Target, Source>(Source& v) {return SourceToTarget(v);} What about converting std::pair<Source,std::pair<Source,Source>> to std::pair<Target,std::pair<Target,Target>>? The issue now is that convert_to(std::make_pair<to, std::make_pair<to,to>>) do not compiles because the conversion of std::pair is named ConvertPair. So we need to specialize the function convert_to for pairs. With C++0x there is no major problem as it allows partial specialization of function templates. With C++98, we need to use a trick; as it allows partial specialization of classes we can define convert_to by as relying to a specific function of a class, as follows: namespace partial_specialization_workaround { template < typename Target, typename Source > struct convert_to { static Target apply(const Source& val); }; } template < typename Target, typename Source > Target convert_to(const Source& val) { return partial_specialization_workaround::convert_to<Target,Source>::apply(val); } So now we can specialize partial_specialization_workaround::convert_to for pairs as follows: namespace partial_specialization_workaround { template <typename Target1, typename Target2, typename Source1, typename Source2) struct convert_to< std::pair<Target1,Target2>, std::pair<Source1,Source2> > { inline static std::pair<Target1,Target2> apply(std::pair<Source1,Source2>& v) { { return std::pair<T1,T2>(convert_to<T1>(from.first), convert_to<T2>(from.second)); } }; } There is one more issue. The preceding design works well with unrelated classes, but what about classes that already define some kind of conversion, using a constructor or a conversion operator. Do we need to make specialization for these conversion? The answer is no. We need just to define the default implementation of the partial_specialization_workaround::convert_to::apply function to just return the explicit conversion. namespace partial_specialization_work_around { template < typename T, typename U> struct convert_to { inline static T apply(const U& val) { return T(val); } }; } What have we learned? Classes or algorithms relying on a conversion by construction or by the conversion operator can be made more generic by relaying in a function that explicitly states this conversion. So instead of requiring Target(from) requires convert_to<Target>(from) The same applies to classes or algorithms relying on the assignment operator. So instead of requiring to = from requires assign_to(from, to); The default implementation of assign_to relies on the assignement operator namespace partial_specialization_workaround { template < typename Target, typename Source > struct assign_to { inline static To& apply(const Source& from, Target& to) { to = from; return to; } }; } template < typename Target, typename Source > To& assign_to(const Source& from, Target& to) { return partial_specialization_workaround::assign_to<Target,Source>::apply(from, to); } So one of the advantages of using this common functions is uniformity. The other is that now we are able to find all the explicit conversions to one type, as we can do with explict casts.

1 0

Re: [boost] Patches in trac...
by Henrik Sundberg 16 Apr '09

16 Apr '09

On Wed, Apr 8, 2009 at 6:24 PM, Marshall Clow <marshall(a)idio.com> wrote: > The conclusion that was reached at the end of the discussion was that we > wanted to get rid of the "Patches" label for Trac tickets, and to move all > the existing patches to either "Bugs" or "Feature Requests". > > What do people think? You might want to add a keyword "patch" to all tickets containing a patch. Just to make it searchable. /$

3 3

Bugfixing Sprints in Cyberspace?
by David Abrahams 16 Apr '09

16 Apr '09

Hi all, At last count, the Boost Trac had over 700 open tickets. I've been thinking I personally could really use an excuse to concentrate on reducing that number (especially the ones assigned to me ;->). It might be fun to try some kind of organized event along the lines that the Ubuntu people use: https://wiki.ubuntu.com/UbuntuBugDay. Does something like this sound like it could work for us? [Okay, maybe we don't have "virtual hugs" and would have to substitute something.] -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 3

[1.39.0] getting started update
by Vladimir Prus 16 Apr '09

16 Apr '09

The attached patch updates getting started to the changes I've did to simplify build process, described in: http://permalink.gmane.org/gmane.comp.lib.boost.devel/188461 and some other existing reality. Specifically: 1. The bootstrap + bjam procedure is documented. 2. The Boost.System library is added to the list of libraries needing compilation. 3. Unix docs are adjusted to use stage/lib everywhere, as opposed to using 'lib' in some cases. Dave, can you review this? I have regenerated HTML and visually inspected them, but HTML diffs are not included for clarity. Thanks, Volodya

2 2

Improved build process
by Vladimir Prus 16 Apr '09

16 Apr '09

Hello, I have completed a set of changes meant to make building C++ Boost somewhat more streamlined, and avoid common pitfalls reported on IRC and mailing lists. In short, C++ Boost can now be build, on Windows, with: bootstrap.bat bjam and on Linux, with ./bootstrap.sh ./bjam I'd imagine that 95% of users won't need anything else, and two commands is a fairly straigh-forward approach. More specifically, the changes I've made are: 1. Some time ago we discussed the configure/make solution: http://article.gmane.org/gmane.comp.lib.boost.devel/181839/ There are two problems with it: - The naming suggests it's automake/autoconf solution, which is not, and users keep on trying automake idioms to find they don't work. - If you just run "bjam" then whatever settings configure made are not considered -- which is very annoying when user has to tweak things beyond what configure offers. Per that thread, I have did two changes: - Renamed configure to bootstrap.sh, avoiding autoconf connotations - Made bootstrap.sh, instead of generating Makefile, generate project-config.jam -- which is automatically read by Boost.Build. 2. Many users forget to specify 'stage' explicitly, and get a pile of libraries in random places. Now, 'stage' is default, and a message saying where libraries go is printed. See: http://article.gmane.org/gmane.comp.lib.boost.devel/188450 3. On Windows, users had to get or build Boost.Jam, and then copy it in %PATH% and then invoke it. Now, bootstrap.bat is a tiny wrapper that builds Boost.Jam and puts it in the root of C++ Boost source tree. 4. On Windows, release libraries were built by default, and debug were not build at all, which does not match default IDE & autolink behaviour. (I think that on Linux, building release by default is fine, since generally debug and release versions are link-compatible). We now build these two variants by default: <variant>debug <threading>multi <link>static <runtime-link>shared <variant>release <threading>multi <link>static <runtime-link>shared These changes are presently on trunk. Most of them are essentially the matter of proper defaults, and proper messages and proper wrappers, not deep hacking, so they are unlikely to disturbing for release. On the other hand, I would very much appreciate comments on "look&feel". So, if you have some time, give it a try and report your experience. I'll take a look at regression results to see if some unexpected breakage appears, and do other round of manual testing on Monday, and then merge this to release branch. Dave, I understand this requires changes to getting started -- for Unix, they are textual replacements only and I have a local patch for that. For Windows, new text is needed that I'll work on as well and should have a patch for your review by Monday. - Volodya

2 1

[TortoiseSVN] Please upgrade if using TortoiseSVN 1.6.0
by Beman Dawes 15 Apr '09

15 Apr '09

There is a bug in TortoiseSVN 1.6.0 that can cause a log request to loop endlessly under certain conditions. When this happens an endless stream of requests is sent to the server. This may be why the svn.boost.org server is getting hammered, and response time is slow. It affects trac too, as it runs on the same server. The problem is fixed in release 1.6.1, so please upgrade to that release if you are currently running TortoiseSVN 1.6.0. Thanks, --Beman

1 0

Cross compilation problem
by Jostein Austvik Jacobsen 15 Apr '09

15 Apr '09

I'm trying to cross compile boost 1.38 for the gumstix motherboard (ARM) like this: wget --tries=10 http://heanet.dl.sourceforge.net/soruceforge/boost/boost_1_38_0.tar.gz tar xzf boost_1_38_0.tar.gz cd boost_1_38_0 echo "using gc : `${GUMSTIXTOP}/tmp/cross/arm-angstrom-linux-gnueabi7bin/g++ -v 2>&1 | tail --1 | awk '{print $3}'` : ${GUMSTIXTOP}/tmp/cross/arm-angstrom-linux-gnueabi7bin/g++ ; " > tools/build/v2/user-config.jam sudo apt-get install bjam sudo bjam --toolset=gcc-arm --prefix=/opt/gumros install It seems to compile correctly, but when I compile my application that depends on Boost (I have remembered to tell it where to find the cross compiled boost), I get this: /home/jostein/gumstix/gumstix-oe/tmp/cross/lib/gcc/arm- angstrom-linux-gnueabi/4.1.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping incompatible /opt/gumros/lib/libboost_thread-gcc-mt-1_38.so when searching for -lboost_thread-gcc-mt-1_38 This looks like Boost wasn't cross compiled at all (or at least incorrectly). Are there any obvious problems with the way I'm doing this? Eventually, does anyone use bitbake and have a working recipe for one of the newer Boost releases (1.35+)? Regards Jostein

3 6

[signals2][interprocess][1.39] Testing variadic templates
by Daniel James 15 Apr '09

15 Apr '09

Hi, The gcc config hasn't been defining BOOST_HAS_VARIADIC_TMPL correctly when C++0x support is available. I've fixed this in trunk but it means that variadic template support hasn't been tested correctly for a while and there are failures in your regression tests. Can you have a look at them before I merge to release? thanks, Daniel

3 2

[thread] atomic
by Sergei Politov 15 Apr '09

15 Apr '09

Hi, I would like to known state of atomic (class/operations) implementation in boost. There are several threads that contains references to atomics, but I cannot find the state of this issue. May be I've overlooked something. I would like to known the following: 1) Is there defined interface for atomics? Where is it if present? 2) What is the state of this work? Currently I use my own implementation of atomic class. It has interface similar to atomic class from intel tbb (also it contains some ideas from tbb, but AFAIK ideas are not under GPL license). Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux (both 32 and 64-bit). I can boostify and prepare it for review, if there is no such work already in progress. Best Regards, Sergei

4 3

Re: [boost] [thread] atomic
by markus2004x 15 Apr '09

15 Apr '09

I have been searching for some standard library of this type for some time. Eventually I wrote my own primitives, taking ideas from tbb and other resources on the web. I also have some containers based on atomics, like non-blocking stacks. I think an atomic-ops library would be a great addition to Boost. If that was available, I would happily throw away all my own code. Best regards, M Sergei Politov wrote: > > Hi, > > I would like to known state of atomic (class/operations) implementation > in > boost. > There are several threads that contains references to atomics, but I > cannot find the state of this issue. > May be I've overlooked something. > > I would like to known the following: > 1) Is there defined interface for atomics? Where is it if present? > 2) What is the state of this work? > > Currently I use my own implementation of atomic class. > It has interface similar to atomic class from intel tbb (also it > contains > some ideas from tbb, but AFAIK ideas are not under GPL license). > Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux > (both 32 and 64-bit). > I can boostify and prepare it for review, if there is no such work > already > in progress. > > Best Regards, > Sergei > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > -- View this message in context: http://www.nabble.com/-thread--atomic-tp22535763p22901742.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[serialization] BOOST_NO_EXCEPTIONS bug
by Vladimir Prus 14 Apr '09

14 Apr '09

Hi, KDE folks has reported that trying to use Boost with exceptions turned off results in duplicate symbol error from Boost.Serialization, like so: kdevclassbrowser. dir/allclassesfolder.o: In function `boost::serialization::throw_exception(std::exception const&)': /usr/include/boost/serialization/throw_exception.hpp:29: multiple definition of `boost::serialization::throw_exception(std::exception const&)' The reason is missing inline, which the attached patch fixes? Robert, is this OK for trunk & release branches? - Volodya

4 5

[mpl] mpl::string, help needed (vacpp, sun, borland)
by Eric Niebler 14 Apr '09

14 Apr '09

(Second try....) I recently added mpl::string (a compile-time string class template) to trunk. I expected horrific portability problems with my use of multi-character literals, but it's not as bad as all that judging from the test results. There are only a few failures on compilers I don't have access to: vacpp, sun and borland. I invite anybody with access to these compilers to "bjam string" in the libs/mpl/test directory, try their hand at fixing the problems and submitting a patch. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[release] README.txt
by Vladimir Prus 14 Apr '09

14 Apr '09

The root of svn tree has file called README.txt that say something about features in 1.34 release. It does not give very good impression -- can this file be either removed or updated? - Volodya

4 5

Re: [boost] [#pragma once]
by Graham 14 Apr '09

14 Apr '09

Incredibuild (xoreax) and other parallel compilation systems have problems with pragma once

7 8

[thread] Ticket #1470 Compilation errors with non-__cdecl calling convention
by Arno Schödl 14 Apr '09

14 Apr '09

Hello, any chance to get this change incorporated? We are running into the same problem. Regards, Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

1 0

[1.39.0][Signals2] Release branch test failures
by Beman Dawes 14 Apr '09

14 Apr '09

Signals2 is failing five tests on all Mac OS testers. See http://beta.boost.org/development/tests/release/developer/signals2.html Please fix or markup. Thanks, --Beman

4 11

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

Question about boost::multi_index::random_access splice()
by Michael Watkins 14 Apr '09

14 Apr '09

It appears that when calling splice() for a random_access index in a multi_index container, the splice calls a copy constructor. This is apparently by design (since the documentation says that it will do an insert) but why was this chosen? Is there another method to move an item from one container to another without having to call the copy constructor? Or can the code be changed to do splice the same way that std::list does? Michael Watkins _________________________________________________________________ Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MS…

2 1

Re: [boost] request for interest in a garbage collection library
by Kasra 14 Apr '09

14 Apr '09

>> 3) gc pointers can point to middle of objects and arrays. >I don't really understand how this works. Would the middle of an >object/array get collected separately from the rest of it? That seems >ridiculous, so I'm confused. hi, I think the following if what was ment: base of array 'x' | v [ 0 ][ 1 ][ 2 ][ 3 ][ 4 ] // an array of 5 elements ^ | pointer to 4-th element (ptr) {c++} gc_free(ptr); remove the entier object 'x' from memory so you don't have to make sure you have a base pointer to 'x' to delete 'x'. This comes handly for example when: {c++[ char* x = (char*)gc_malloc(5); char* end = x + 5; set_zero(x, 5); while(x != end && *x != 0) { // error, x should have been al zero gc_free(x); // note x doesn't point to base // of the allocated memory anymore! } ]} With Best Regards -- Kasra

1 0

atomic_count::operator++ return type
by JOAQUIN M. LOPEZ MUÑOZ 14 Apr '09

14 Apr '09

Hi, Some of the implementations of boost::detail::atomic_count::operator++ return a long (vg. Win32) while for others the return type is void. Is it feasible to change this so that a long (i.e. the value of the atomic count after incrementing) is returned always? As it happens, I have a usage case for this in Boost.Flyweight. Thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 10

Re: [boost] BoostCon 2009 Early Registration Extended to April 26th
by Brian Wood 14 Apr '09

14 Apr '09

David Abrahams writes: on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote: >> Would you agree that recoding that takes advantage of C++ 1998 >> should be higher priority than C++0x? > > In general, maybe. For BoostCon, no. > >> For example, Boost Serialization doesn't use hinted inserts with >> (mulit)set or (multi)map. > > Have you submitted a ticket for that at http://svn.boost.org? I created ticket 2945 now. I'd like to make it to a BoostCon sometime, but am not sure about this year. -- Brian Wood Ebenezer Enterprises www.webEbenezer.net

1 0

[mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
by Larry Evans 13 Apr '09

13 Apr '09

The vault file: http://preview.tinyurl.com/cbr9k3 demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? TIA. -Larry

5 20

link=shared and runtime-link=static
by Vladimir Prus 13 Apr '09

13 Apr '09

In present, with --build-type=complete all variants with <link>shared and <runtime-link>static are explicitly not built, because they are deemed risky. The code to exclude those variants is written in such a way that: 1. It produces pile of unclear messages. 2. It prevent build of those variants no matter what -- even if you specify this explicitly on command line, you'll get nothing built. I am fixing (1) and this allows (2) to be changed. Should I? In other words, what should happen if user say: bjam link=shared runtime-link=static ? Options are: 1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted. I believe that on Linux, (4) is most appropriate. I don't know about Windows. Comments? - Volodya

3 6

[convert] Version in the Vault ready for review.
by Vladimir.Batov＠wrsa.com.au 13 Apr '09

13 Apr '09

After listening to many views, opinions, suggestions I've re-done boost::convert and would like it scheduled for a review. It is certainly nowhere as MPL and still not perfect. However, I believe it will be very useful to many developers (like me) not satisfied with lexical_cast and not (yet?) needing (or ready for) something like upcoming Spirit 2.0. Overall, after weighing all pros and cons, I am reasonably happy with the current interface and implementation. It does not implement all that have been discussed and suggested. It is most unlikely implemented the way some would like it to see. However, I had to make choices I felt comfortable with and I feel the current interface is minimal, readable and allows for further growth. With that review-request I would like to avoid opening up another round of discussions if 'from' was a good, bad, mediocre choice. I feel we've exhausted that topic and I would like people to simply vote if they find the functionality needed. I am most certainly prepared to eat my humble pie if the vote is 'no'. Still, I am very much looking forward to any implementation-related suggestions/corrections or new ideas we have not discussed so far. The current interface can be summed up as with as little as int i = convert<int>::from(str); // Throws on failure int i = convert<int>::from(str, -1); // Returns -1 on failure More details can be found in the accompanying document (just remember I am not Shakespeare). If/when we decide to extend that by incorporating, say, Boost.Parameter and/or Spirit, then it might be as int i = convert<int>::from(str)(radix_ = 10, more_parm_ = ...); int i = convert<int>::from(str)(some Spirit related stuff); I am prepared to look into it further... if this initial proposal is accepted... otherwise, it'll be less work for me. :-) Thank you everyone who participated in the lexical_cast/convert discussions. Your views, opinions, suggestions were very helpful and educating and are very much appreciated. I hope I did not forget anyone in the "acknowledgements" list. The file called boost-string-convert.zip can be found in the Vault at http://www.boostpro.com/vault/. Thanks, Vladimir.

6 17

[threads] making parts of Boost.Threads header-only
by joaquin＠tid.es 13 Apr '09

13 Apr '09

Hi, Looks like a sensible part of Boost.Threads, namely that dealing with mutexes and locks, would be header-only but for its relying on boost/thread/exceptions.hpp, whose implementation is located at /libs/thread/*/exceptions.cpp. Given that this .cpp mostly consists of extremely simple definitions (as simple as do-nothing functions in many cases), would it make sense to move this to inline definitions in boost/thread/exceptions.hpp thus making mutexes and locks header-only? This would greatly enhance the appeal of this part of Boost.Threads, as having to link a separate module is a considerable burden. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

12 24

[1.39.0][Build] Release branch failures on all platforms
by Beman Dawes 13 Apr '09

13 Apr '09

Although most of the tests pass, default_toolset is failing on all platforms. There are a few other scattered failures. See http://beta.boost.org/development/tests/release/developer/build.html Please fix or markup, Thanks, --Beman

3 2

[1.39.0][Spirit] Release branch test failures
by Beman Dawes 13 Apr '09

13 Apr '09

Spirit is failing a few Darwin tests. A couple of the problems are caused by exceeding -ftemplate-depth-128, so that might require a fix to the toolset. See http://beta.boost.org/development/tests/release/developer/spirit.html Please fix or markup. Thanks, --Beman

2 1

[1.39.0][Filesystem] Release branch test failures
by Beman Dawes 13 Apr '09

13 Apr '09

Filesystem is failing two tests on two Mac OS testers. See http://beta.boost.org/development/tests/release/developer/filesystem.html Please fix or markup. Thanks, --Beman PS: Yep, me too:-)

1 0

[1.39.0] Schedule
by Beman Dawes 13 Apr '09

13 Apr '09

My apologies for lack of progress on 1.39.0. Hopefully I can put in more time on it this week, and we can get the beta out sometime next week. The release will remain open for bug fixes until Monday, April 20th, without having to ask permission to merge. --Beman

1 0

[thread_local] emulation !?
by Kasra 13 Apr '09

13 Apr '09

Hi, I have been using a mechanism to emulate [thread_local] storage for some time now. However, I am aware of boost.thread has thread local heap. The difference is with thread_local emulator we have similar c++0x syntax working seemlessly. for example: thread_local <int> tlocal_integer(-1); // assign the global thread_local value void foo(int i) { *tlocal_integer = i; std::cout << this_thread::get_id() << " : " << *tlocal_integer << endl; } int main() { boost::thread_group tg; for(int i=1;i<500;i++) tg.create_thread(bind(&::foo, i)); *tlocal_integer = 0; std::cout << "main : " << *tlocal_integer << endl; tg.join_all(); return 0; } Wondering if anyone is interested into porting this to boost???

1 0

[mpl][docs]why use list?
by Larry Evans 13 Apr '09

13 Apr '09

Comparing the vector doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/vector.html which contains: supports constant-time insertion and removal of elements at both ends, and linear-time insertion and removal of elements in the middle. with the list doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/list.html which contains: supports constant-time insertion and removal of elements at the beginning, and linear-time insertion and removal of elements at the end and in the middle. shows these documents indicate no reason to prefer list over vector but does indicate a reason to prefer vector over list. Is there any reason to prefer list over of vector? -regards, Larry

4 13

[build] error: No best alternative for ./install
by Bjørn Roald 13 Apr '09

13 Apr '09

Hi, I am trying to test trunk against external projects using boost. But "bjam install" has stopped working recently on my Linux box. $ sudo ./bjam install error: No best alternative for ./install next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched ...found 1 target... I have no idea what this means and is basically stuck. Any help? -- Bjørn

2 2

new version of Join library
by Yigong Liu 13 Apr '09

13 Apr '09

Hello, i just uploaded a new version of Join library to Vault/ Concurrent programming. A brief summary of Join library: an asynchronous message coordination and concurrency library based on JoCaml and Cw. It provides a high level api of asynchronous ports, synchronous ports, chords and joints which support multithreaded applications and orchestration of asynchronous messages. There are some major changes for this new version: 1. originally the library is structured as 2 layers: a port api at bottom and a function api at top. In this new version, function level api is dropped to simplify the interface and implementation. There are some benefits coming with it: 1> the signature of chord's function can be directly mapped from the types of its ports, there is no need for argument wrappers (async_o, synch_o) anymore. so a thread safe message queue can be defined as: template <typename T> class msg_que : public joint { public: async<T> send; synch<T,void> recv; msg_que() { chord(recv, send, &msg_que::proc); } T proc(void_t, T s) { return s; } }; 2> we can use boost::lambda or phoenix to define chord's function; so the above class becomes: template <typename T> class msg_que { public: async<T> send; synch<T,void> recv; msg_que() { joins().chord(recv, send, _2); } }; 2. apply "pimpl" idiom to major port classes and joint class. the benefits of this: 1> port/joint classes play well with standard c++ containers and other libraries 2> better control of lifetime of port/joint objects 3> we can do JoCaml (functional) style "Join" programming, instead of Cw's class based design. For example the msg_que can be created using "factory" function as in JoCaml: template <typename T> tuple<async<T>, synch<T,void> > create_msg_que() { async<T> send; synch<T,void> recv; joins().chord(recv,send,_2); return make_tuple(send,recv); } So the code which uses this "factory" function look like this: ... async<int> send; synch<int,void> recv; tie(send,recv) = create_msg_que<int>(); //spawn 2 threads, thread1 creates data and send it, thread2 receives and use data spawn(bind(thread1_func, send)); spawn(bind(thread2_func, recv)); The documents and samples are updated. You can view them from the following link. http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.h… You can download it from Vault / Concurrent Programming or the project website http://channel.sourceforge.net Comments and corrections are highly appreciated. Thanks Yigong

1 0

boost regex build problem
by Qihong Wang 13 Apr '09

13 Apr '09

Hi, I feel awkward to post almost the same question again. But I really have a problem when I build 32 bits boost.regex with icu support on a 64 bits Linux machine. If I build 64 bits regex with icu support, they are fine. If I build 32 bits regex without icu support, they are fine. When I tried to build 32 bits regex with icu support, I used command for ICU building ./runConfigureICU Linux --disable-64bit-libs ./configure --prefix=/home/qhwang/mylibs_32/icu --disable-64bit-libs I checked icu libraries they are not dependent on 64bits libraries. So I'm confident they are 32bits. But when I use the command to build 32 bits regex ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete --address-mode=32 --architecture=x86 -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install Bjam showed ...failed updating 4 targets... ...skipped 12 targets... ...updated 7477 targets... there were only static libraries built. When I linked them to my program which were also compiled in 32 bits, the linker complained the libraries were incompatable. Could someone give me some help again? Thanks in advance. Qihong

3 6

[fusion] repetitive_view
by Stjepan Rajko 12 Apr '09

12 Apr '09

Hello, I just noticed `repetitive_view` in boost/fusion/view. It doesn't appear to be documented, but judging from the test, it appears that repetitive_view<Sequence> is an infinite repetition of the elements of the sequence. Is that correct? I would find this extremely useful, but I'm slightly put off by the lack of documentation and the fact that it results in a (not currently officially supported?) infinite sequence. What is the status of repetitive_view? Is it safe to use? Stjepan P.S. we have discussed infinite sequences before: http://archives.free.net.ph/message/20080716.025311.1b54b65e.da.html

2 3

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

Re: [boost] BoostCon 2009 Early Registration Extended to April 26th
by David Abrahams 12 Apr '09

12 Apr '09

The following message is a courtesy copy of an article that has been posted to comp.lang.c++.moderated,comp.std.c++,comp.lang.c++ as well. on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote: > Would you agree that recoding that takes advantage of C++ 1998 > should be higher priority than C++0x? In general, maybe. For BoostCon, no. > For example, Boost Serialization doesn't use hinted inserts with > (mulit)set or (multi)map. Have you submitted a ticket for that at http://svn.boost.org? > I believe Boost Multi Index does. In the > performance section here -- > http://webEbenezer.net/comparison.html -- there's a subsection > on Load/Receive tests that mentions this. I also mentioned > this subject twice in this thread: > http://lists.boost.org/boost-users/2009/03/45712.php > > If anyone cared or even noticed wasn't clear as there was > no response to that particular point. Different library maintainers take different approaches to responding to reports on the Boost list. Specific Trac tickets (especially with patches attached, as you seem to be able to provide) are a little harder to leave dangling because to make them go away you have to explicitly close them, so I suggest you try that approach with one ticket per issue. > For some reason I doubt the author or anyone else bothered to improve > the library in this way and the 1.39 version of the Serialization > library will have the same weak performance in this area. > > Additionally and more importantly, now the C++ Middleware > Writer has support for several boost::intrusive containers. > Neither Boost Intrusive nor Boost Serialization have > serialization support for any of the intrusive containers. > The Boost Instrusive containers are superior to the > standard containers in a number of ways, so this gap is > big. > > While working to update parts of Boost to be able to > take advantage of C++ 2010 (or 20110), makes sense to > me, I think the items I mentioned should be higher > priority than the C++0x work. A Boost bugfixing sprint sounds like a great idea, but that can happen in cyberspace (the way Ubuntu does it). I invite you to come to the Boost developers' list and kick one off. I would certainly be grateful for an excuse to focus on closing Boost Trac tickets. In fact, it sounds like a good thing to mull over at BoostCon At BoostCon I want to take advantage of the face-to-face time to do things that are a bit more educational, less critical-path, and that can really benefit from having a bunch of people in the same room. I think exploring how C++0x features interact in real C++ libraries is one of those. > It's not as cool or sexy though. That's an issue, too. To make it worthwhile for people to travel across the country to BoostCon, you need to put "cool" things on the program ;-). > The first item should be relatively easy to address, which makes it > all the more surprising that as the releases go by it doesn't get > addressed. Remember that addressing any given issue in a Boost library is basically up to one person: whoever is maintaining that library. Maintainers are volunteers, and each one arranges his priorities differently. But in the case of something posted on the -users mailing list whose thread sorta trailed off, I wouldn't be surprised if the issue has fallen off the maintainer's radar. I suggest getting it into the tracking system. > The second item, though is a different story. Anyway, > even if you are only able to address the first item by the time > BoostCon is over, I'll be impressed. Well, it's not really up to me, and I don't /think/ Robert Ramey is planning to come to BoostCon this year. > And since I'm able to point out two weaknesses like this with one > library, there may be other problem areas in other libraries. Definitely: https://svn.boost.org/trac/boost/report/1 Looks like we have 766 open issues right now :-( > This could be incorporated into the pricing of the conference: $499 > gets you into the C++98 "fixer" and $599 gets you into the C++0x > "fixer." :) Yeah, not very practical. Those sessions are just two 3-hour segments out of a whole week of material. We're not making the conference itself into one big sprint. Take a look at the program: http://www.boostcon.com/program Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

boost::interprocess mixing heap and shared memory ?
by Oncaphillis 11 Apr '09

11 Apr '09

Working with boost::interprocess I came across the following question. using namespace boost::interprocess; // ... Assume that I've declared all the necessary allocators // ... for chars and std::pair<my_string,my_string> here typedef basic_string<char,my_char_allocator_t> my_string; typedef map<my_string,my_string,std::less<my_string>,my_string_string_allocator> my_map; managed_shared_memory shm(open_or_create,"BogusMemory",0x1000) my_map *the_map = some_how_construct_map_in_shared_memory(shm); // So now I have a map residing in shared memory // The only way to search within this map I could // find was the following. my_map::iterator i = the_map->find(my_string("BOGUS",my_char_allocator_t(shm))); This might throw since the search string is constructed within shared memory although it is only needed temporary and destructed right after the statement. Is there a way to use heap or stack memory for thinks like that ? Thank you very much O.

2 1

Default variants on windows
by Vladimir Prus 11 Apr '09

11 Apr '09

Per: https://svn.boost.org/trac/boost/ticket/2899 we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later. Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built. - Volodya

10 18

How to open parallel port
by master master 11 Apr '09

11 Apr '09

Is there any library exist for opening parallel ports? I know for serial it is "serial_port". I worked with it and it is working fine. For parallel communication; which class(library) is needed. -Rahul Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

1 0

Thread-safety issue with Boost Function?
by Sohail Somani 11 Apr '09

11 Apr '09

Hi, I was just looking through the Boost Function source and noticed the following in assign_to: // Note: it is extremely important that this initialization use // static initialization. Otherwise, we will have a race // condition here in multi-threaded code. See // http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/. static vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; However, my copy of the C++ standard seems to say this regarding local statics in section 6.7: The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with constant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope. I read this to mean that an implementation may decide to initialize stored_vtable statically or the first time the block is entered. So I think that this means we cannot rely on static initialization behaviour. If you agree, then a simple fix for this might just be: template<typename VTable, typename Invoker, typename Manager> struct vtable_static_constructor { static VTable vtable; }; template<...> VTable vtable_static_constructor<V,I,M>::vtable = { {&Manager::manage, &Manager::invoke } }; assign_to() { ... vtable_type & stored_vtable = vtable_static_constructor<vtable_type,invoker_type,manager_type>::vtable; ... } If not, could you please point me to where in the standard this is guaranteed to be statically initialized? It would help me decide whether or not to fix some other code that has a similar pattern, if nothing else. Thanks in advance! -- Sohail Somani http://uint32t.blogspot.com

1 0

Re: [boost] [#pragma once]
by jbosboom＠uci.edu 10 Apr '09

10 Apr '09

> If unrecognized pragmas are ignored, then I don't see why boost > developers should jump > through a hoop to satisfy the "el-cheapo" compilers. In other words, if > a compiler gives > a warning about the #pragma-once, then let the programmer turn off the > warning locally > for the build, which is usually done in a single location within a > makefile. Well, what about the compilers that recognize #pragma once but don't implement it correctly? Or implement it as well as they can on their platform but somehow differ from other compilers? Also, there was once a version of GCC that would launch nethack or rogue when it encountered #pragma once. That's a perfectly legal thing for it to do (if not all that helpful). My point is that since we can't depend on the semantics of #pragma once, we ought not to use it. --Jeffrey Bosboom

1 0

BoostCon 2009 Early Registration Still Available
by David Abrahams 10 Apr '09

10 Apr '09

In recognition of the economic climate, and in order to make possible the maximum participation this year, we've extended the early registration deadline for BoostCon until April 26th, so BoostCon is still only $599. BoostCon has always been a great place to network, find out what is happening in the C++ community, and learn about the coolest C++ libraries being developed within and outside of Boost --- and this year will be better than ever. The official schedule is now live at http://www.boostcon.com/program. A few highlights of the "mouth-watering content" (in the words of one enrollee) are: * A keynote address from Andrei Alexandrescu called "Iterators Must Go." * Troy Straszheim's presentations on how high-energy physicists are using Boost to process massive datasets as they go "Icefishing for Neutrinos" and on Kamasu, his library for offloading computation to your machine's GPU. * Two hands-on sessions where we'll start recoding parts of Boost for C++0x, applying rvalue references, variadic templates, decltype, and advanced SFINAE capabilities using the latest GCC. * "Practical C++ Test-Driven Development with Boost.Test and Bmock," by Asher Sterkin * A session on compiler construction using Boost.Spirit v2, from Hartmut Kaiser and Joel de Guzman The complete list of sessions covers a wide range of other Boost and C++-related topics. Please have a look: http://www.boostcon.com/program/sessions. The quality of BoostCon has always depended on its diverse and interesting participants, so bring your ideas, questions, and experience, and sign up now! http://www.boostcon.com/registration See you in Aspen, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Interest check: constant input matching manipulator
by Eugene Wee 10 Apr '09

10 Apr '09

Hi, Recently, I observed in an online community a question on whether C++ had a direct replacement for a call to scanf("a=%d", a) for some int a, using std::cin. The response given was to read the input as a string and then parse it. Another user noted that "iostreams would be more useful if it had the ability to match constant portions of the input". Looking at what already exists in the standard library and Boost, there does indeed seem to be no direct way to match such expected constant input. Boost.Regex and Boost.Tokenizer are indirect in this case (and possibly overkill), and Boost.Format is about output stream formatting only. Boost.Spirit appears to provide a way with file_iterator, but a manipulator seems more appropriate here considering that the functionality is quite simple. Does anyone think that adding such a manipulator to Boost would be desirable? I expect the syntax to be along these lines (names and namespaces to be decided): std::cin >> match("a=") >> a; where a failure to match would place the input stream in a failed state. It would also be possible to use a std::basic_string instead of a string literal converted to a pointer to its first element as the argument. I have already written such a manipulator, so if anyone is interested, I can provide my sample source. Regards, Eugene Wee

5 10