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

Re: [boost] [threads] making parts of Boost.Threads header-only
by Brian Wood 09 Apr '09

09 Apr '09

Anthony Williams writes: >Emil Dotchevski <emildotchevski(a)gmail.com> writes: >> >> I am against such a move. Boost Threads requires linking for other >> features which makes it one of the few libraries in Boost that can be >> properly designed to avoid unnecessary physical coupling. Unless >> something is proven to cause performance problems it should not be >> inlined, regardless of how simple it is. > >Wow, that's a hard line you've drawn there. I'm not sure I agree. The >only reason this matters is if you're going to be changing the >implementation and don't want to recompile the code that uses the >header. For boost users, the implementation only changes if they change >boost versions, and in that case I would expect people to recompile >anyway --- I wouldn't trust something compiled against boost 1.37 to >link against a 1.38 lib, for example. I'm sure you know more about Boost than I do, but I disagree that the implementation only changes when users change versions. There are fixes that have to be applied by users to libraries from time to time. I tend to agree with Emil's arguments here. Brian Wood Ebenezer Enterprises www.webEbenezer.net

6 6

[exception] updated in the trunk and in the release branch
by Emil Dotchevski 09 Apr '09

09 Apr '09

Two new functions added: current_exception_cast (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_c…) and current_exception_diagnostic_information (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_d….) There is a minor breaking change in the interface of the get_error_info function: it used to return shared_ptr, now it returns just a raw pointer: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/get_error_info.html. This limits the lifetime of error_info objects to not exceed the lifetime of the exception object, which could make custom platform-specific error_info optimizations possible (the type of the pointee is guaranteed to be copyable, so if the user needs to hold on to it after the exception object has expired, they can simply copy it instead of relying on shared_ptr to keep it afloat.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Polynomial] Review Result
by John Maddock 09 Apr '09

09 Apr '09

Apologies for the delay in putting this together... First off I'd like to thank the author for submitting this for review - I wish all our SOC students were similarly diligent! :-) We received a number of reviews of this library, but none were in favor of acceptance in its current form, and most thought that there was still a fair bit of work to do to get the library into shape. However, most thought that the library could be accepted into Boost given sufficient changes/enhancements. Therefore the library is not accepted into Boost at this time, but I would like to encourage the author to continue to work on the library and resubmit at a future time. In no particular order the main review comments are summarized below: Principal comments: * Documentation, especially the background is inadequate and needs a good proofreading a) From the examples are nothing that a competent programmer couldn't figure out from the declarations. Some more interesting or useful examples would be nice, particularly for things like the special forms. It's not exactly clear what I would do with those functions. b) There is no documentation or references to the various algorithms used. Those, too, would be nice. c) Doc.html appear to have been created 'the Hard Way'. Would be much more useful and look nicer if produced with the Quickbook, Doxygen... toolchain. And make it maintainable by other people. * Use of constructors and assignment operators that modify their arguments isn't acceptable - best to find another interface for this. * Several reviewers noted that the code didn't build for them, in particular log2 isn't available on all platforms/compilers. * evaluate_polynomial() and evaluate_polynomial_faithfully() take their coefficient arguments in the opposite order of all the other functions/constructors in the library, without providing any reason for that choice. That's seems somewhat surprising. I'd suggest fixing that, or at the very least providing an argument in the documentation why this makes some sense. * Rename evaluate() to horner() and provide evaluate() as an inline call to horner(). * Rename evaluate_faithfully() to compensated_horner(). * Things that say "Be careful about this" generally need fixing. * It would be nice to have operator* and operator/ as well as *= and /=. * Considering they share the same core algorithm, it might be nice to have a function that could do division and return the remainder at the same time. Something like poly::divide(P &divisor, P &quotient, P &remainer) * FFTs are good for multiplying polynomials above a certain size, but they are rather heavy for small polynomials and can lead to unexpected crosstalk between terms. There should be an option for * that doesn't use the FFT, and it should be the default for small polynomials. * operator/= has a hardcoded "std::vector<double> new_coefficients" that later gets rounded?? This should be fixed to work with any type that fulfills the necessary conceptual requirements (and tested and documented what those requirements are - it would be nice if they were the same as the rest of Boost.Math). * The name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). * the Polynomial class provides a fairly minimalist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i,f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p * We had one feature request for extending support to finite fields. * This constructor: template<typename U> polynomial(const U& v); had me a little confused at first - is there any advantage to making this a template rather than simply accepting a const FieldType& as the single argument? * It's not clear from the documentation what this constructor does: polynomial(InputIterator first1, InputIterator last1, InputIterator first2); It needs to clearly state the degree of the resulting polynomial and whether it passes through all/any of the points - in fact maybe the constructor should have a final parameter for the degree of the polynomial and use least-squares fitting when required? Likewise for the member function template<typename InputIterator> void interpolate(InputIterator first1, InputIterator last1, InputIterator first2); * Operators: the / and % operators need good descriptions of what they do, given that no exact division is possible. As someone else has already noted, a function to calculate divide and remainder in one step would be useful too. * GCD: presumably this is restricted to polynomials with integer coefficients? If so it should say so. * Evaluation: The docs should say what method is used for the evaluate_faithfully method and give a reference. Renaming as someone else suggested may be better too, but personally I'm easy either way on that. I'm not sure whether there should be an evaluate_by_preconditioning method, shouldn't the polynomial "know" that it has been preconditioned and react accordingly. I haven't looked/checked but do the usual arithmetic operators still work if the polynomial has been preconditioned? I assume probably not, but if that's the case there should be a stern warning to that effect, *and* checks in code to prevent us from doing something stupid :-) BTW, preconditioning can be applied to polynomials of any degree I believe it's just that it gets hard to implement in the generic case. In addition I'd like to see the evaluation functions templated, so that the type being evaluated can differ from FieldType - it would surely be quite common for example to create and manipulate polynomials with integer coefficients, but then want to evaluate on a floating point type. There is machinery in Boost.Math BTW to handle the mixed argument-promotion and calculation of the result type, let me know if you need help in using this. * Special Forms: the functions provided do *not* generate polynomials in the alternative forms, but rather generate the named polynomial of order N, which is rather less useful, but at the very least the docs need updating to reflect this. * test_arithmetics.cpp fails on cygwin: or at least it did once I added a using std::pow; to start of operator*= to get things compiling. * None of the code builds with msvc: there are a couple of issues here: friend polynomial<FieldType> boost::math::tools::gcd<>(polynomial<FieldType> u, polynomial<FieldType> v); Needs to be changed to: friend polynomial<FieldType> boost::math::tools::gcd<FieldType>(polynomial<FieldType> u, polynomial<FieldType> v); to get msvc to Grok the code. After that there are a bunch of failures due to the use of log2 which msvc doesn't support (and since it's not part of the std other compilers are likely to complain too). * I haven't looked too hard at the implementation, except to echo the comments posted previously that the Conceptual requirements for FieldType need documenting and *testing*. There are concept checking classes and archetypes in Boost.Math which may be of use here. Again, shout if you need help in figuring out how to use these. I did notice that operator*= for example uses std::complex<double> internally which effectively limits the precision that can be achieved - to be useful to me - and to replace the existing "implementation detail" polynomial class in Boost.Math - I would need the polynomial class to be usable with arbitrary precision types such as NTL::RR or mpfr_class. Also as previously noted, multiplication of small polynomials may well be more efficient with the "naive" algorithm, so some performance tests and experimenting is required here. Related to this, use of "round" should be restricted to types that are known to be integers? Regards, John Maddock Review Manager for Polynomial Library.

2 1

why the output is different?
by Dongfei Yin 09 Apr '09

09 Apr '09

I write some code like this: #include <iostream> using namespace std; class Base1 { public: typedef Base1 base; void f() { cout<<"Base1::f()"<<endl; } }; class Base2 { typedef Base2 base; public: void f() { cout<<"Base2::f()"<<endl; } }; class A : public Base1 , public Base2 { public: A() { base::f(); } }; void main() { A a; } the output is : Base1::f() But if the definition of class A modified like this, class A : public Base2 , public Base1 { public: A() { base::f(); } }; the out will be: Base2::f() the output depends on the sequence of base class, that means the "typedef" in base class is unreliable. complier gives no warning. I try these code at both VS2005 and VS2008, the result are same.

2 1

[math] Help needed porting to AMD64/Linux platforms
by John Maddock 09 Apr '09

09 Apr '09

Folks, I'm still having trouble with some failures that appear to be specific to Linux on AMD64, if anyone with access to such a platform can help me out I'd be most grateful. You can test whether your machine exhibits the issue by: cd into libs/math/test and bjam gcc test_hypergeometric_dist1 If that fails, then I'm looking for the output from the following program to try and track down the cause of the error (caution this will be quite voluminous!): #define BOOST_MATH_INSTRUMENT #include "boost/math/distributions.hpp" int main() { double x = 30520, r = 130605, n = 130605, N = 523360, p = 1.315394088731268169855067478460234e-53, q = 1; boost::math::hypergeometric_distribution<> hyp(r, n, N); unsigned x_found = quantile(hyp, p); BOOST_MATH_INSTRUMENT_VARIABLE(x_found); return 0; } Perplexed yours, John.

3 5

[proto] _value doesn't enforce zero arity
by troy d. straszheim 09 Apr '09

09 Apr '09

I see some funny behavior when misusing _value: #include <boost/proto/proto.hpp> namespace bp = boost::proto; int main(int, char**) { bp::terminal<int>::type t = {0}; bp::terminal<int>::type hmm = bp::value(t * 2); bp::terminal<int>::type uhm = bp::_value()(t * 2); bp::terminal<const int&>::type hrm = bp::value(2 * t); bp::terminal<const int&>::type feh = bp::_value()(2 * t); } Which does compile.. but the docs say that _value requires an expression of zero arity. Here as usual is an attempt at a patch, to see if I'm learning anything: BOOST_MPL_ASSERT_RELATION( remove_reference<Expr>::type::proto_arity_c, ==, 0L); in the body of struct _value in transform/args.hpp. How'd I do? -t

6 16

[Testing] Sandia-tiger-x86 intel-darwin compiler crashes
by Emil Dotchevski 08 Apr '09

08 Apr '09

I'm wondering if someone with access to that compiler can help me diagnose the problem and/or submit compiler bug reports. Here are the tests that seem to crash the compiler: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… This one has no log, but might not be a crash: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Patches in trac...
by Marshall Clow 08 Apr '09

08 Apr '09

At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things. Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached. 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". I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say. What do people think? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

Moving property map library into a directory
by Jeremiah Willcock 08 Apr '09

08 Apr '09

The Boost Property Map Library (property_map) currently consists of a number of files in the top-level boost/ include directory. It would probably be better to move all of them into a subdirectory, especially as Nick Edmonds and I will be adding new files and directories into that library soon. Should I do that move? I will update Boost.Graph; are there other libraries in Boost that use property_map? -- Jeremiah Willcock

4 4

Re: [boost] Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by tinkertom 08 Apr '09

08 Apr '09

I figured out what my problem was: When constructing a boost::mutex::scoped_lock in 1.33 the second parameter is a boolean. In 1.38, boost::mutex::scoped_lock (defined as unique_lock) constructor is overloaded using different types as the initial lock state instead of a single constructor with a boolean. In the constructor I now have to use adopt_lock_t, defer_lock_t, or try_to_lock_t as the second parameter. In 1.33: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, false); In 1.38 now looks like: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, defer_lock_t()); -Tom -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Shorter link to getting started
by Vladimir Prus 08 Apr '09

08 Apr '09

I would like to modify the configure script to mention getting started, so that user knows where to look for information, but unfortunately, the current URL is a bit long: http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html It is 77 characters, so it does not leave any space for any other text. Can the website administrators arrange for some shorter redirect to be available? Say http://www.boost.org/getting_started/unix-variants.html ? Thanks, Volodya

4 3

[data_binding] Lets bind data
by Kasra 08 Apr '09

08 Apr '09

Hi, I am looking for interest in data_binding techniques in C++. The idea is to have a class that could bind to a list of data and when ever any of them is changed the value of the binder is changed too: data_bindee<mpz_class> x; data_bindee<mpz_class> y; typedef tuple<mpz_class,mpz_class> my_bind_tuple_type; struct my_bind_pred_type { template<typename BinderT> void operator(BinderT& me, my_bind_tuple_typeT t) { me.x = get<0>(t); me.y = 2 * get<0>(t); } }; data_binder<struct { mpz_class x,y; }, my_bind_tuple_type, my_bind_pred_type> point(x, y); // when ever data of x and y is changed the value of point // is updated too. Any suggestions?? Kasra With Best Regards -- Kasra Nassiri

1 0

Preliminary progress on Boost.Python py3k support
by Haoyu Bai 08 Apr '09

08 Apr '09

Hi, I did some preliminary work on BPL py3k support in these days. With Troy's help we have a py3k SVN tree in sandbox now, which is branched from trunk. I also tried to compile BPL with Python 3, and by following the error report of the compiler, I did some patch - now we have 14 .cpp files out of 28 in total can be compiled. The patch is committed, you can see it here: [2]. Please point me out if the code has something don't conform to Boost coding policy. There's also something interesting, maybe a bug I caught, for example: (Search the changeset to see details) 39 // XXX(bhy) Potentional memory leak here since PyObject_GetAttrString returns a new reference 40 // const char *mod = PyString_AsString(PyObject_GetAttrString( self_, const_cast<char*>("__module__"))); 41 PyObject *mod = PyObject_GetAttrString( self_, "__module__"); Also I found some potential problem with Py_ssize_t, I will take this as a chance to fix them. The biggest problem I see still is the "Text Vs. Data Instead Of Unicode Vs. 8-bit" in py3k. As we discussed and the suggestion by Niall [3], we have a clear solution for this and I will work towarding this. The other changes in py3k such as PyObject_HEAD change, int type removal and unbound method removal also affected Boost.Python's code, but they don't require logical change of BPL code and easy to handle. Hopefully in the end of this summer, we will have a Boost.Python library with Python 3 support! Thanks again for many people's help! References: [1] https://svn.boost.org/trac/boost/browser/sandbox-branches [2] https://svn.boost.org/trac/boost/changeset/52118 [3] “Nabble - Python - c++-sig - Some thoughts on py3k support,” http://www.nabble.com/Some-thoughts-on-py3k-support-td22564813.html. -- Haoyu Bai

2 1

[interprocess] Assign to shared_lock from scoped_lock
by Chard 08 Apr '09

08 Apr '09

If I have (template args removed for brevity): shared_lock sh_lock(mutex); scoped_lock sc_lock(move(sh_lock), try_to_lock); // Try for exclusive if (sc_lock) { ... sh_lock = move(sc_lock); // Drop back to shared *** not available } Should that assignment operator be available? Currently I'm working around this with: sh_lock.swap(shared_lock(move(sc_lock))); [or, alternatively: sh_lock = move(shared_lock(move(sc_lock))); ]

2 1

Re: [boost] [Any] Reference counting
by Michael Howell 08 Apr '09

08 Apr '09

Steven Watanabe <watanabesj(a)gmail.com> wrote: > Have you read http://www.gotw.ca/gotw/045.htm? I haven't read it, and have looked into atomic numbers, but couldn't find the "Boost Way" to do it (except perhaps poking around with shared_ptr innards). I wanted to use intrusive counts, since we have control over the object we are sharing. Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >If you want to improve the performance of any, the thing to do is to add > a small buffer optimization such that all buildin types (or equally > small UDT) are created on the stack. I'll look into that. Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > Also, any is a value type. We do not want it to have reference > semantics. So you'd need to use COW. Actually, copy on write/implicit sharing is what I was proposing, if you had looked at the code. > Hence this is fairly useless, especially since we're getting move > semantics soon. "Soon" is relative. The trunk GCC may support it instantly (may already), but Debian Stable won't, nor will MSVC (both which will be used for a good while). Also, you usually copy the value when you store it, which may or may not involve writing. For example: #include <boost/any.hpp> using namespace boost; struct example { any variable; }; int main() { example object; example object2; any value = "I Love Boost!"; object.variable = value; object2.variable = value; return 0; } Thanks for replying, everyone. -- Michael Howell mhowell123(a)gmail.com

4 5

"[gsoc] Thread scheduler support for boost" [Re: for vicente.botet]
by Indradip Ghosh 07 Apr '09

07 Apr '09

Hi Vicente, Sorry for having missed your question earlier on my intended GSOC proposal. I actually intended to design the fine-grained scheduler for threadpool class itself. My detailed application is listed here in the googlesites: http://sites.google.com/site/threadpoolschedulergsoc2009/ Please let me know if you have any questions/ comments regarding my proposal. Thanks and Regards, Indradip. > Message: 7 > Date: Mon, 30 Mar 2009 08:36:36 +0200 > From: "vicente.botet" <vicente.botet(a)wanadoo.fr> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: <boost(a)lists.boost.org> > Message-ID: <C1B76DB53B1544F9B2C5618DB7A708EF@viboes1> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I'm wondering this shouldn't be considered as an extension of the Boost.Thread library more that the Boost.ThreadPool library. The ThreadPool library can be improved once these extension are in place, but also other application or libraries using threads. > > Let me know if I'm missing someething? > > Best, > Vicente

1 0

Performance measurement
by Govindan, Nandagopal (GE Healthcare) 07 Apr '09

07 Apr '09

Hi, I would like to know how performance measurement( time & memory ) done in boost. Do boost has some following APIs to measure performance?? Profiler.start() Code to be measured Profiler.stop() Printstatistics() Regards Nandagopal

3 3

[gsoc] improving any and variant
by Mathias Gaunard 07 Apr '09

07 Apr '09

A few little ideas that could eventually be joined to be a single GSoC project: - Allow visitation for Any. This can actually be generalized to any object that exposes a type_info, such as polymorphic objects. Techniques, including non-portable ones based on name mangling, could be experimented to get more efficient dispatch. - Add SBO to any. - Improve variant so that the functor doesn't require to expose a result_type. The result_type can be automatically deduced by "joining" all the possible return types obtained by boost::result_of. - Allow the easy construction of a visitor from lambda expressions, with a syntax like variant<int, std::string> a = "foo"; int b = match(a).with( args<int>(_1), args<std::string>(size(_1)) ); instead of the potentially more verbose struct my_visitor : static_visitor<int> { int operator()(int a) { return a; } int operator()(const std::string& b) { return b.size(); } }; variant<int, std::string> a = "foo";; int b = apply_visitor(my_visitor(), a);

5 5

Intrusive list/ilist and rbtree marshalling support
by Brian Wood 07 Apr '09

07 Apr '09

I'm happy to announce that version 1.8 of the C++ Middleware Writer is available on line -- http://webEbenezer.net/cgi-bin/samb.cgi<http://webebenezer.net/cgi-bin/samb.cgi>. This version adds support for the following: * Exclusive marshalling support of boost::intrusive::list and boost::intrusive::rbtree. Neither Boost Intrusive nor Boost Serialization offer serialization support of the Intrusive containers. Rather than having two types called 'list,' we refer to boost::intrusive::list as an ilist. An example of this support is here -- http://webEbenezer.net/rbtree_marshalling.html<http://webebenezer.net/rbtree_marshalling.html>. * Several new options on the user interface including: + An "Error Handling" option that indicates whether the code should be written using return codes or exceptions. The exception support is new in this release. This option affects the signatures of the generated marshalling functions. + A "Code Structure" option that indicates whether the code should be written in header-only format or separated interface and implementation files. The separated interface and implementation support is new in this release. This option also affects the signatures of the generated marshalling functions. + A choice between unsigned short or unsigned int as the type for constants written by the C++ Middleware Writer. Constants that identify messages and user defined types are written by the software. Previously the constants were always unsigned ints. * A mechanism to turn off automatic code generation for a type. Adding a // comment within a class declaration with "hand_written_marshalling_code" in the text of the comment will disable default code generation for that type. For example, class bag { // hand_written_marshalling_code ... }; As the comment indicates, you will provide the implementation of the marshalling functions for this class. This option is not available with /* */ comments. Additionally, I would like to say that I find the Intrusive library to be sound and am using it internally in the C++ Middleware Writer. Thanks to the authors: Olaf Krzikalla and Ion Gaztañaga. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[program_options] multitoken arguments
by Carlo Medas 06 Apr '09

06 Apr '09

Dears, we've been using boost::program_options and it works great. We just found a minor thing, which could be an issue, and I'm reporting it to you: when specifying and using a multitoken argument, it actually works only if put as last parameter of command line; in any other case, it eats all remaining parameters. My specification is as follows: desc.add_options() ("output,o", bpo::value<std::vector<std::string> >()->multitoken(), "use output setup for discovery/scan"); If then I want to use it like follows, it works: > fing -p1 -p2 -p3 -o 1 2 3 But if the user inverts the order, it does not work anymore, meaning that p3 is eaten by -o option. > fing -p1 -p2 -o 1 2 3 -p3 Is this a known limitation? Or maybe my specification above is not correct? Thanks in advance, Carlo Medas

2 4

Re: [boost] Shorter link to getting started
by Anders Dalvander 06 Apr '09

06 Apr '09

ghost(a)cs.msu.su wrote: > I would like to modify the configure script to mention getting started, > so that user knows where to look for information, but unfortunately, > the current URL is a bit long: > > http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html > > It is 77 characters, so it does not leave any space for any other text. > > Thanks, > Volodya What happens after 77 characters, do characters start falling off the edge of the screen? Hasn't that theory been disproved yet? J/K. It would be nice to have shorter URLs, the non version specific URL is even a character longer: http://www.boost.org/doc/libs/release/more/getting_started/unix-variants.ht… Regards, Anders

3 2

"[gsoc] Thread scheduler support for boost"
by Indradip Ghosh 06 Apr '09

06 Apr '09

Hi , I am writing to poll for suggestions/ questions/ comments regarding my GSOC application listed here : http://sites.google.com/site/threadpoolschedulergsoc2009/ Please let me know if I could clarify any concerns. Thanks, Indradip.

1 0

[boost test] boost testing framework xml schema‏
by Daniel Carrara 06 Apr '09

06 Apr '09

I would like to know where I can find the xml schema for the test logs produced at the end of the testing with --log_level=all and _log_format=XML. Thanks, Daniel _________________________________________________________________ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009

2 1

[mpl][doc]bug: prior.html should have Bidirectional Iterator requirement.
by Larry Evans 06 Apr '09

06 Apr '09

The prior.html document: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/prior.html says prior requirement is that Iterator be a Forward Iterator; yet, http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/forward-iterato… makes no mention of prior. Also, compiling prior on a list iterator shows: /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/next_prior.hpp:40: error: no type named 'prior' in 'struct boost::mpl::l_iter<boost::mpl::list1<char> >' Hence, the prior requirement should be Bidirectional instead of just Forward Iterator. -regards, Larry

2 1

My ideas for GSoC project
by Balša Raičević 05 Apr '09

05 Apr '09

Hello, I'm a Computer Science student from Faculty of Mathematics, University of Belgrade. I am interested in working on The BGL. I have a lot of experience with C++ and code refactoring also, since I've done a lot of tutoring and encountered a lot of strange students' code :) I have taken a deep look at BGL ( which is why I'm writing my proposal so late :) ) and to some extend its extension - The Parallel Boost Graph Library. I am mostly interested in graph partitioning, as I find them very useful for parallel computing. I understood the importance of it when I had to do some major calculations for numerical approximations and wanted to use all the CPU power available :) In the project idea list ( https://svn.boost.org/trac/boost/wiki/soc2009#Graphpartitioning) it's said that it would be good to implement algorithms similar to those in METIS ( http://www.cs.umn.edu/~metis <http://www.cs.umn.edu/%7Emetis>). I've read some of George Karypis' "Publications Related to Graph Partitioning", so I was wondering if I could discuss with someone which algorithms would be good to implement, and of course, how. I found little, if any, discussion about that in mailing list archive. Other thing I would really like to see is hypergraph partitioning. I see that implementing hypergraphs in the BGL is one of GSoC projects, so I would like to know would it be possible, if that project is not awarded to anyone for this summer, to do basic implementation of a hypergraph, or (since I see there is already a discussion about that) if somebody else would do that project, to collaborate on hypergraph partitioning algorithms. Last, but not least, an important question: I would like to use this work as part of my Master's Thesis. I looked at GSoC FAQ ( http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#cours…) so I guess it is OK with the program, but I would still like to discuss it with potential mentor. Thanks ahead, Balsa

1 1

boost::shared_mutex performance
by Tim Blechmann 05 Apr '09

05 Apr '09

hi all, i did some performance tests of boost::shared_mutex and a wrapper class to posix pthread_rwlock_t, which provides most of the interface from the sharedlockable concept (without the timed locking, which should be easy to add). i am not sure, whether the boost::shared_mutex class is supposed to give some guaranties (like fairness), that my wrapper implementation doesn't provide ... it does outperform the boost::shared_mutex implementation by a factor of about 2.5, though (linux, x86_64) benchmark code and wrapper class are attached. seeing these speedups, would it be reasonable to introduce a boost::native_shared_mutex class, based on a native implementation? best, tim -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

1 0

Naga Rama Lokesh Gopu, student - link id zaq1xsw2 , Google Summer of Code
by Lokesh Gopu 05 Apr '09

05 Apr '09

Hi sir , My name is Naga Rama Lokesh Gopu, My link id is zaq1xsw2, I have submitted a proposal on creating new math library with advanced functions, But i have submitted in the last hour before deadline. That s the reason i cant mention clearly in that proposal. i don't know how to prove my self that i am eligible for this project, i submitted the details of my project proposal. In rush you may made my proposal ineligible. I am ready to do code almost all the day more than 3 months. my contact number is (+91 9246476974) I cant find the individual email address who like to do job of mentor. I am ready to do any mathematical project of our wish , Because i am damn good in those topics of good depth. I am not writing any story here, I just want to make u understand my self. If any one like to do mentoring for my project . Please make my proposal eligible , and make me to work harder in this summer. the polynomial function in the boost libraries are not in good depth , i can do more work on the all such topics. I cant clearly mention the work i can do.. Please reply me your opinion about my project on creating new math library. Please understand me i am very enthusiastic to do that in this summer . Finally make my proposal eligible, and mentor my project . Reply is must, even a string of reply! Thank you for understanding me

1 0

[Any] Reference counting
by Michael Howell 05 Apr '09

05 Apr '09

The attached patch add reference counting "implicit sharing" to Boost.Any. It is my first patch to Boost, so it will probably need some changes. -- Michael Howell mhowell123(a)gmail.com

5 5

[gsoc] Students who have an application pending
by troy d. straszheim 04 Apr '09

04 Apr '09

Please try to keep your application up to date with mailing list archive links (via gmane or whatever) to the heads of threads about your proposals. Just add something like a "links to discussion" section at the bottom. This will really help us. If no discussion has taken place here about your proposals, if you update your proposal with a link to this message, you'll still get points for having seen this message at all... :) -t

5 7

[gsoc] Range/Iterator in Boost.Crypto
by Kasra 04 Apr '09

04 Apr '09

Hi all, I have got more excited about GSoc so I have been working ahead of schedule to get boost.crypto going. At this time I have completed my schedule until 05/05/2009. Here I need some advice on the design principles for my interface. I have decided to implemented a generic buffer called crypto_buffer, this buffer is intended to implement bufferings for a stream (stream ciphers/hash algorithms). The class head is as follows: // this class manages 1 block of state_size that the stream is deposited on // also arbitary numbers of buffers that the underlying transformer // wished to include. // when the buffer # 1 is filled in with data the transformer is called // to process the buffer and this is continue untill the end of buffer template< class Transformer, // the algorithm that will transform the buffer size_t Buffers, // the # of buffers this transformer will manage bool FixedOutput, // if the output buffer is constant bool BitBuffered // byte or bit buffered? > class crypto_buffer { public: typedef Transformer transformer_type; typedef BOOST_DEDUCED_TYPENAME transformer_type::size_type size_type; ... // the size of input block which ensured optimal buffering performance static constexpr size_type transform_size = transformer_type::transform_size; // the size of blocks which is stored between transition states static constexpr size_type state_size = transformer_type::state_size; private: transformer_type m_transformer; public: // create a new stream void create(); // transform all but the final stream block template<CryptoBuffer bufferT> size_type transform(bufferT& , const bufferT&); // transform the final block of our stream template<CryptoBuffer bufferT> size_type transform_final(bufferT& , const bufferT&); }; Notice the 'CryptoBuffer' concept. The question is how to implement this concept. Iterators and Ranges is suggested by other previously, however, how could we impelemnt them for the above interface? The reason for my question is I am not sure if I could implement a library that doesn't require for example a block-cipher to have 1-block of input in contiguous memory. For hash functions and stream ciphers is much easier since the contiguity requirement could be a byte or a bit which could be done easily. Any suggestions?? With Best Regards -- Kasra Nassiri

1 0

[GSOC] Regarding the project Boost.DeVector
by Satyam Shekhar 04 Apr '09

04 Apr '09

Hi, I am interested in doing the Boost.DeVector project for GSOC 2009. I had certain queries regarding this project: 1. Does the standard specify any sort of implementation for deque, or does it only specify the requirements and interface? I ask this because if we assume a dynamic array implementation which grows on both the sides, implementing 'reserve', and specifying the size of the chunk should be a trivial task. 2. What are the examples of the low-level operations for which this container is over-encapsulated? Regards Satyam

6 14

[gsoc] Application period ends today / review period begins.
by troy d. straszheim 04 Apr '09

04 Apr '09

Student application period ends today at 19:00 UTC, 12 Noon PDT. Then we have until the 15th to review and rank all (over 50 as of now) student proposals and match them with mentors. -t

4 7

[serialization] serializing std::bitset
by Kenny Riddile 04 Apr '09

04 Apr '09

I need to serialize a std::bitset. I found an implementation by Brian Ravnsgaard Riis from 2006 in the vault that doesn't work with xml archives out of the box since it fails to use nvp wrappers internally. Should I just add the nvp wrappers or is there anything more current for serializing std::bitsets?

3 5

Release schedule
by Vladimir Prus 03 Apr '09

03 Apr '09

Hi, the calendar at http://www.boost.org/development/index.html has: 1.39.0 Closed for major code changes for today and: 1.39.0 Closed except by permission for next Friday, Apr 10th. I have a few questions: 1. Is this schedule still up-to-date? I did not notice any reminder emails. 2. I assume this refers to all commits to release branch? 3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk). 4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12. Thanks, Volodya

4 4

[statechart] Bug when switching inner-states?
by George van Venrooij 03 Apr '09

03 Apr '09

Hi, I have attached a test program that gives some curious results, indicating the statemachine does not reach its proper state when performing state changes in orthogonal regions. The machine attached contains a main state that handles an "update" event. That main state contains 2 inner states, one of which also handles the "update" event. If that inner state transits to another state and back again, the "update" event no longer arrives at it, which in my opinion is a bug. If I modify the state machine so it does not have 2 but only 1 inner state, then the behavior matches my expectations. Could someone please verify if this is bug or tell me if my usage scenerio is incorrect. Regards, George van Venrooij Organic Vectory http://www.organicvectory.com #include <boost/statechart/state_machine.hpp> #include <boost/statechart/event.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/custom_reaction.hpp> #include <iostream> namespace bs = boost::statechart; using namespace std; // The main event, should be handles by a sub-state and the main state struct update_event; // An event triggering the sub-state to switch struct toggle_event; // A dummy event struct other_event; // Sub-states in 2 orthogonal regions struct state_1A; struct state_1B; struct state_2A; struct state_2B; // Main state struct parent_state; // State machine consisting of the main state struct machine : bs::state_machine<machine, parent_state> { }; typedef boost::mpl::list < state_1A , state_2A > inner_states_t; // The main state has 2 orthogonal sub-states struct parent_state : bs::simple_state<parent_state, machine, inner_states_t> { typedef boost::mpl::list < bs::custom_reaction <update_event> > reactions; bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct update_event : bs::event<update_event> { }; struct other_event : bs::event<other_event> { }; struct toggle_event : bs::event<toggle_event> { }; struct state_1A : bs::simple_state<state_1A, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> , bs::custom_reaction <update_event> > reactions; state_1A() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1B>(); } bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return forward_event(); } }; struct state_1B : bs::simple_state<state_1B, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> > reactions; state_1B() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1A>(); } }; struct state_2A : bs::simple_state<state_2A, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2A() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct state_2B : bs::simple_state<state_2B, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2B() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; int main(int argc, char* argv[]) { machine m; cout << "0. Initiating state machine:" << endl; m.initiate(); cout << endl << "1. Processing 'other_event':" << endl; m.process_event(other_event ()); cout << endl << "2. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "3. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "4. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "5. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "6. Processing 'update_event':" << endl; m.process_event(update_event()); return 0; } ////////////////////////////////////////////////////////////////////////// // Program output after building with VC 9 and Boost 1.37.0 // // Note the different event handling in step 6. as compared to step 2. // although the machine should be back in the same state. ////////////////////////////////////////////////////////////////////////// /* 0. Initiating state machine: state_1A::state_1A state_2A::state_2A 1. Processing 'other_event': state_2A::react 2. Processing 'update_event': state_1A::react parent_state::react 3. Processing 'toggle_event': state_1A::react state_1B::state_1B 4. Processing 'update_event': parent_state::react 5. Processing 'toggle_event': state_1B::react state_1A::state_1A 6. Processing 'update_event': parent_state::react */

2 1

Mutex vs Semaphore
by Jean-Sebastien Stoezel 03 Apr '09

03 Apr '09

Hi, I need to synchronize 2 threads, that is once one is done doing something, it should activate another thread that had been waiting in a pending state. I see the thread library offers mutexes and nothing else. I guess mutexes would do, but I do not believe I should use mutexes for my application. Mutexes are supposed to provide mutual exclusion when critical data is accessed. Semaphores should be used for what I want to do. However, I only see semaphores available in the interprocess library. I only need inter-thread synchronization, and going the long way with the interprocess library seems a bit overkill. It may be an ideology issue here. I would appreciate your comments on what to use in this case. Thanks, Jean

4 5

[gsoc] Min Cost Flow in Boost Graph library
by shilp gupta 03 Apr '09

03 Apr '09

Hey, I am interested in contributing to the Boost Graph library with algorithms. Some of my suggestions are, - minimum cost flow - weighted bupartite matching - maximum flow (based on blocking flows) I had a few questions to ask, Is there any significant progress already in development or implementation of minimum cost flow algorithms in Boost? To the best of my knowledge, Boost does not have a structure for bipartite graphs. Would it be appreciated if I work on one? I know that these can be represented using standard graph structures without much loss, but the simplicity (and scope) of bipartite graph's can be used to reduce constants in the run times of algorithms on them - maximum flow using blocking flows infact runs in O(sqrt(V)E) time for calculating the maximum cardinality matching in the bipartite case. Thanks! Regards Shilp Gupta

2 1

BOOST::SIMD - handling double : precision vs speed
by Joel Falcou 03 Apr '09

03 Apr '09

SIMD algorithms for double precision seem to be rather hard to do right. It's difficult to get the right precision with respect to the scalar reference as scalar algorithm take advantages of the internal 80 bits floating points register, thus leading comparison between our implementation and the reference to yields things like 3000 ulp (ie 10^-13 RMS instead of 10^16). Fixing this is difficult and even if it's possible for some algorithms, the average speed-up then drop to less than 10% - ie as fast as an unrolled scalar call over the SIMD vector elements. What should we enforce : precision or speed ? Or is the 10^-13 RMS enough ? Of course, this is mostly a problem on current SIMD extension in which vector of double only have 2 elements. It may be different with upcoming AVX and Larabee featuring larger vectors. Discussions welcome. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

7 6

A Boost.NumericAdaptor library to support big numbers
by Bruno Lalande 02 Apr '09

02 Apr '09

Hello, Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest. The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries. In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers. The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here. Would there be an interest in adding such a library into Boost? Bruno Lalande Barend Gehrels

7 10

Back to Boost.SIMD - Some performances ...
by Joel Falcou 02 Apr '09

02 Apr '09

I'm still working on a potential Boost.SIMD proposal despite the apparent lack of interest by the list. Last discussion spawned the fact that actual performances figures may be interesting. So here's some (see end of mail). This table show for a subset of non-trivial functions the cycles needed to compute one value in scalar, using SSE2, some precision concerns and the actual speed-up. Most of them are super-linear because either : 1/ libc algorithm is badly implemented, or 2/ non-SIMD architectural difference between SSE2 FPU and scalar FPU leads to additional speed-up Most transcendental functions used a SIMD evrsion of the old yet useful Cephes C library based around various polynomial estimations. Results on Altivec processor are roughly the same except for transcendental where the use of a proper FMA instead of sequence of mul-add increases performances.For trivial function like +,-,*,/, I was happily surprised that indeed gcc is able to generate SIMD code. Alas, gcc auto-SIMD speed-up never exceed 2.54 while our code can go up to 3.5. Concerning the problem of interface and support of odd-ball vector size in a platform independant fashion, we use the remark of Matthias and provide a vec<T,C> class in which the vector cardinal can be speficified (and is equal to the native cardinal of said type by default). Things like vec<double,5> are handled as boost::array and provide same interface and set of functions. for any given functions, it cna be applied either to any vec<T,C> types or any native SIMD type (__m128 in SSEx or vector xxx in Altivec). Syntaxic sugar like v = v+4 is provided and perform consatnt splatting before SIMD evaluation. This still has to be boostified and made independant of the whole project it depends on. Once done, a preliminary version will be uploaded into the Vault. Current target architecture are : - SSE2, SSSE3,SSE3 - AltiVec for PPC and Cell processor (a patched version of boost is needed) Comments and questions welcomed. || -------------- || --------------- || scalar || -------------- vector ---------------- || ---- || || || || cycles ||cycles | ulp | rms | peak || s-up || || --------------------------------------------------------------------------------------------- || || abs_ || float || 2.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 2.4 || || acosh_ || float || 148.2 || 30.2 | 1 | 9.15e-09 | 1.19e-07 || 4.9 || || acos_ || float || 261.8 || 14.7 | 3 | 7.01e-08 | 2.38e-07 || 17.8 || || arg_ || float || 5.0 || 1.2 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || asinh_ || float || 152.8 || 32.4 | 1 | 1.22e-08 | 1.19e-07 || 4.7 || || asin_ || float || 256.5 || 11.6 | 2 | 5.32e-08 | 2.28e-07 || 22.1 || || atanh_ || float || 123.9 || 20.4 | 2 | 2.27e-08 | 4.55e-07 || 6.1 || || atan_ || float || 160.7 || 12.7 | 1 | 3.55e-08 | 6.74e-08 || 12.7 || || bitofsign_ || float || 5.1 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 6.1 || || boolean_ || float || 5.4 || 1.0 | 0 | 0.00e+00 | 0.00e+00 || 5.4 || || cbrt_ || float || 152.5 || 39.7 | 1 | 2.76e-08 | 7.77e-08 || 3.8 || || ceil_ || float || 16.6 || 2.8 | 0 | 0.00e+00 | 0.00e+00 || 5.9 || || cosh_ || float || 211.5 || 19.1 | 2 | 4.00e-08 | 1.83e-07 || 11.1 || || cos_ || float || 112.2 || 14.6 | 1 | 2.98e-08 | 1.11e-07 || 7.7 || || cospi_ || float || 103.6 || 12.1 | 1 | 3.43e-08 | 1.19e-07 || 8.6 || || cot_ || float || 142.8 || 17.8 | 3 | 5.54e-08 | 2.38e-07 || 8.0 || || cotpi_ || float || 142.1 || 17.1 | 6 | 9.62e-08 | 4.08e-07 || 8.3 || || exp10_ || float || 169.3 || 32.1 | 1 | 2.88e-08 | 1.19e-07 || 5.3 || || exp_ || float || 171.3 || 19.3 | 1 | 2.60e-08 | 1.19e-07 || 8.9 || || expm1_ || float || 294.1 || 42.6 | 3 | 2.89e-08 | 1.94e-07 || 6.9 || || floor_ || float || 16.9 || 2.7 | 0 | 0.00e+00 | 0.00e+00 || 6.4 || || gd_ || float || 602.4 || 35.8 | 3 | 3.93e-08 | 2.46e-07 || 16.8 || || indeg_ || float || 2.2 || 0.8 | 0 | 2.59e-08 | 5.94e-08 || 2.7 || || inrad_ || float || 2.2 || 0.8 | 0 | 2.53e-08 | 5.94e-08 || 2.6 || || iseqz_ || float || 5.5 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.3 || || iseven_ || float || 45.0 || 2.3 | 0 | 0.00e+00 | 0.00e+00 || 19.9 || || isfin_ || float || 5.9 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.6 || || isflint_ || float || 38.3 || 1.8 | 0 | 0.00e+00 | 0.00e+00 || 21.4 || || isgez_ || float || 6.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 7.4 || || isgtz_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || isinf_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || islez_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isltz_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isnan_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isnegative_ || float || 5.6 || 1.1 | 0 | 0.00e+00 | 0.00e+00 || 5.0 || || isnez_ || float || 5.4 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.2 || || isnotfinite_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isodd_ || float || 47.8 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 18.8 || || ispositive_ || float || 5.6 || 1.3 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || log10abs_ || float || 107.5 || 17.3 | 2 | 6.59e-08 | 2.12e-07 || 6.2 || || log10_ || float || 105.4 || 16.9 | 2 | 6.58e-08 | 2.12e-07 || 6.2 || || log1p_ || float || 149.7 || 18.8 | 1 | 9.16e-09 | 1.19e-07 || 8.0 || || log2abs_ || float || 107.5 || 17.2 | 1 | 1.89e-08 | 1.19e-07 || 6.3 || || log2_ || float || 105.5 || 17.1 | 4 | 1.90e-08 | 2.51e-07 || 6.2 || || logabs_ || float || 107.5 || 23.6 | 1 | 4.36e-08 | 1.19e-07 || 4.6 || || log_ || float || 108.3 || 15.4 | 1 | 9.12e-09 | 1.19e-07 || 7.0 || || mantissa_ || float || 22.1 || 5.0 | 0 | 0.00e+00 | 0.00e+00 || 4.4 || || oneminus_ || float || 3.3 || 0.8 | 0 | 5.16e-10 | 5.96e-08 || 4.0 || || oneplus_ || float || 3.4 || 0.8 | 0 | 2.87e-10 | 5.74e-08 || 4.1 || || rec_ || float || 37.4 || 4.3 | 0 | 2.48e-08 | 5.92e-08 || 8.8 || || round_ || float || 43.7 || 5.5 | 0 | 0.00e+00 | 0.00e+00 || 8.0 || || rsqrt_ || float || 105.4 || 11.3 | 1 | 3.62e-08 | 8.81e-08 || 9.3 || || signedbool_ || float || 9.3 || 0.9 | 0 | nan | 0.00e+00 || 10.6 || || sign_ || float || 12.1 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 4.9 || || signnz_ || float || 12.1 || 1.4 | 0 | 0.00e+00 | 0.00e+00 || 8.5 || || sinh_ || float || 267.2 || 19.1 | 3 | 2.38e-07 | 3.84e-07 || 14.0 || || sin_ || float || 110.5 || 17.0 | 1 | 2.98e-08 | 1.12e-07 || 6.5 || || sinpi_ || float || 115.8 || 14.4 | 1 | 2.98e-08 | 1.10e-07 || 8.0 || || sqr_ || float || 2.0 || 0.7 | 0 | 2.53e-08 | 5.94e-08 || 2.9 || || sqrt_ || float || 68.3 || 7.1 | 0 | 2.62e-08 | 5.96e-08 || 9.6 || || sqrtabs_ || float || 68.3 || 7.0 | 0 | 2.61e-08 | 5.96e-08 || 9.7 || || tanh_ || float || 206.4 || 20.8 | 197 | 1.63e-07 | 1.77e-05 || 9.9 || || tan_ || float || 153.0 || 17.8 | 2 | 4.18e-08 | 1.45e-07 || 8.6 || || tanpi_ || float || 156.2 || 18.0 | 2 | 4.16e-08 | 1.48e-07 || 8.7 || || --------------------------------------------------------------------------------------------- || -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

9 23

[Boost.Asio] Compiler warning in address_v6.hpp
by Fraser Hutchison 02 Apr '09

02 Apr '09

I'm new to boost and am looking for a bit of advice if possible. asio/ip/address_v6.hpp lines 58 & 355 yield the following compiler warnings when flag -Wmissing-braces (which is enabled by -Wall) is set: missing braces around initializer for 'u_char [16]' missing braces around initializer for 'in6_addr::<anonymous union>' These can be avoided by amending e.g. line 58 from boost::asio::detail::in6_addr_type tmp_addr = IN6ADDR_ANY_INIT; to boost::asio::detail::in6_addr_type tmp_addr = {{IN6ADDR_ANY_INIT}}; Is this worth submitting a bug report and patch for this, or not?

3 2

personal samsung
by Fernando Cacciola 02 Apr '09

02 Apr '09

11 6 100 6359

1 1

[gsoc] Proposal - Boost.Matrix - DRAFT RFC
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, Following the discussion in the threads: "[boost][gsoc] Interest check for 3d geometry proposal" "[boost] [gsoc] fixed size matrix class?" I post a draft of my proposal with a request for comments. Following the suggestions I decided to scale down the proposal to a polished and production-quality fixed-size Boost.Matrix library, with a big emphasis on correctness and performance. The application follows: Abstract ========= uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t N, std::size_t M, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations ( matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. Rationale ========== Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors -- a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable -- due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side ( optimization ). Primary deliverables ===================== Boost.Matrix library, with the following features: a) a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind b) specializations for efficient vector (1xN matrix) handling c) operators for readable but efficient vector/matrix math d) operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation Secondary deliverables ======================= a) performance test suite, for testing optimizations b) unit tests for the whole library providing full operation coverage and code-coverage c) documentation for the whole library in the BoostBook format d) efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS in particular) Bonus deliverables =================== ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) a) optional (compile-time controlled) integration with Boost.SIMD to boost (no pun intended) performance b) performance tests on different compilers/architectures, further optimizations c) support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) Design issues ============== a) compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) b) usage of templates to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) c) usage of expression templates to eliminate temporaries in expressions d) care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) e) design with architecture-dependent optimizations in mind ( ease of expansion ) f) keeping all the standard boost practices, including workarounds for non-conformant compilers Project schedule ================= I plan to do at least weekly progress reports with emphasised design decisions (however well designed in the first phase, reality will probably change the design afterwards at least a little). Progress reports will be directed to the medium established with the mentor (blog, list or only direct communication). This will be my only job once summer starts, and will be treated as such during program coding timeline ( full-time schedule ) -- a week may fall out for a short vacation. Preplanning (April 20 - May 23) -------------------------------- Most of the major design decisions need to be done before the program starts. A end-user interface for the library should be established before the program starts. This will be summed up in a report that will be sent to boost-dev with a request for comments. Phase 1 (Correctness) - (May 24 - June 14) ------------------------------------------- A working basic (non-optimized) implementation, and a full test suite for the basic operations will be created. Goal for this phase is to provide a correct and working implementation. Basic usage document. Phase 2 (Functionality) - (June 14 - July 5) --------------------------------------------- Performance test suite. Compiler-level optimizations ( expression templates, unrolling, etc ). Basic library compatibility ( STL container, uBLAS ). Concept checking. Phase 3 (Optimization) - (July 6 - July 26) -------------------------------------------- Optimizations for vectors, optimizations for specific vector and matrix sizes, optimization checking through performance test suite. Code review for eventual optional architecture optimization ( Boost.SIMD for example ). General optimization of code. Update of documentation. Phase 4 (Finalization and bonuses) - (July 27 - August 10+) ------------------------------------------------------------ Testing on as many architectures as possible ( probably will need some help here ). Fixes. Cleanup of the code where needed. A report of the implementation that again will be posted to boost-dev with a request for comments. Here is included also buffer time if there will be delays in one of the former phases. If not, work will continue with the Bonus deliverables. Brief resume ============= I'm a Computer Science PhD student (2nd year) at the University of Wroclaw (Poland), in the field of Computer Graphics. My interests lie in Game Programming and Design, with a special hunch for Real-time Proceduraly Generated Content. I actively run self-designed courses and lectures at the University ( 3ds MAX course last year, Game Programming lecture this semester, and probably an Advanced C++ course next semester ). Currently, until the end of the semester, I'm working full-time at Tieto corporation, doing a large scale project for Nokia. Previously I worked at a smaller computer game company working on a massive multiplayer game. I've successfully taken part in two last GSoC's creating a Procedural City Generator for the BZFlag project. I consider myself a fairly competent C++ programmer, although I only recently discovered its true strengths ( learned to properly use and write in the style of STL, started reading Boost sources, and got hooked into C++0x ). I'm currently using the language both at work and for my own projects. The latter include a 3D game engine (in progress), and an unannounced space combat/trading game. I am a big fan of roguelike (ASCII) games, and managed to write several roguelikes up to date, the most famous one of them being DoomRL ( http://doom.chaosforge.org ) that did even get mentions in contemporary gaming magazines. Homepage : http://chaosforge.org/ IRC nick : Epyon E-mail : kornel.kisielewicz at gmail.com / epyon at cs.uni.wroc.pl -- regards, Kornel Kisielewicz

7 14

Extrinsec conversions (Was [safebool] Can we generalize it and put it intoutilities?)
by vicente.botet 01 Apr '09

01 Apr '09

----- Original Message ----- From: "Eugene Wee" <crystalrecursion(a)gmail.com> To: <boost(a)lists.boost.org> Sent: Wednesday, April 01, 2009 4:10 AM Subject: Re: [boost] [safebool] Can we generalize it and put it intoutilities? > > Hi, > > On Wed, Apr 1, 2009 at 6:20 AM, Vladimir Batov > <vladimir.batov(a)wrsa.com.au>wrote: > >> I glanced over "explicit conversion operators" in C++0x. It did not struck >> me as >> relevant to safe_bool. Care to elaborate? > > > It is relevant since you can say, define an explicit conversion function to > convert to bool, and yet avoid the very problems with say, also allowing > implicit conversion to int, that the safe bool idiom is used to avoid. In > other words, it is a language feature directly designed to replace the safe > bool idiom, and more. Hi, Thanks for the clarification. Even if the following is not related to the safe bool idiom it is related to conversions. The current standard allows to define intrinsec coversions, i.e. conversions that are defined either as a conversion operator on the from class or as a constructor on the to class. Vladimir StringConvert proposal seems to go towards a conversion from/to strings (If I've understood?). lexical_cast can be seen as an extrinsec converions of unrelated types via a common type stream type. I have proposed a generic convert_to template function that generalize extrinsicaly the explicit convertion of unrelated types. template <typename To, typename From> To convert_to(From&); One difference is that for C++0x explicit conversion you can write From from; To to=To(from); While for unrelated types you are forced to write From from; To to=convert_to<To>(from); The other difference is that constructors and conversion operators can be implicit, while the convert_to function can not. Do you think that it could be an interest in extending the C++0X standard to take care of these extrinsically defined conversions between unrelated types? Have a sens to have extrinsec conversions which implicitly convert? Should this convert_to<T> operator be considered as a friend class of T? I know that this is out of the scope of Boost, but I just wanted to know your opinion before posting to comp.lang.c++.moderated. Apologize if this has already been discused. Best, Vicente

3 2

[safebool] Can we generalize it and put it into utilities?
by Vladimir.Batov＠wrsa.com.au 01 Apr '09

01 Apr '09

Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities? struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result; explicit safebool(bool v) : value_(v) {} operator result() const { return value_ ? &safebool::internal_bool : 0; } private: void internal_bool() const {}; bool value_; }; That way all we (and the users) will have to do to deploy the technique will be class Foo { ... operator safebool::result() const { return safebool(my_condition); } }; This seems simple and hassle-free. Thanks, Vladimir.

8 19

[gsoc] Concept check
by Kasra 01 Apr '09

01 Apr '09

Hi, I have decided to use the following concept for my gsco proposal regarding boost.crypto. The dilema at the moment what is the minimum contiguous ranges concept? Any suggestiong over the design? concept CryptoBuffer // which is a variable sized buffer that // uses an allocator that securely deletes. concept BlockCipher { typename value_type; typename size_type; typename traits_type; auto key(void) const throw(); template<CryptoBuffer CB> void key(const CB& ) const throw(invalid_key_size); template<CryptoBuffer CB> void encrypt(CB&, const CB& ) const throw(bad_state); template<CryptoBuffer CB> void decrypt(CB&, const CB& ) const throw(bad_state); }; struct crypto_stream_parallel_encryption { }; struct crypto_stream_parallel_decryption { }; struct crypto_stream_parallel : crypto_stream_parallel_encryption, crypto_stream_parallel_decryption{ }; concept ModeOfOperation { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept StreamCipher { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept HashAlgorithm { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type state_size; static constexpr size_type transform_size; void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type finalise(const CB1&); }; Any suggestiong over the design? -- Kasra

1 0

has_operator_new
by Robert Ramey 01 Apr '09

01 Apr '09

I've made a TRAK item to request a new type traits feature - has_operator_new. I've included an implementation and a test - both type_traitsified. Hope you can see fit to check it out, and if it's OK, check it in. Let me know when you do this. Once this is in, I can clear a dependent feature request TRAK item from the serialization library. Robert Ramey

2 3

[gsoc] Interest check for 3d geometry proposal
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, I was instructed on the #boost-soc channel to post the initial interest check on the GSoC proposal on the dev list, so here it is. It was inspired by one of the project proposals from 2006 (Geometry Library). As a known fact Boost begins to be used in the gaming industry. Following the idea of code reusage, there are several generic algorithms and components reused by virtually every 3d gaming engine. Most particulary this is 3D math. Sure, Boost has a linear algebra library graph algorithms, and a proposed geometry library, yet what is missing is a high-performance low-dimensional linear algebra library ( vectors and matrices up to the 4th dimension ). Side by side we have also a need of several 3-dimensional algorithms -- including, but not limited to intersection tests, inclusion tests, volume bounding, and several computational geometry algorithms. My suggestion would be creating a 3d specific geometry library for boost, with reasonable performance and the most used algorithms. I'd be happy to work on such a library as a GSoC project. My goal is to assess the initial interest in such an GSoC proposal idea before preparing and posting a more detailed description. -- regards, Kornel Kisielewicz http://chaosforge.org/

22 56

GSoC 2009
by Julian Mautner 01 Apr '09

01 Apr '09

Hi everyone! I'm Julian, 21 years old, student at the university of Innsbruck, Austria. Currently I'm making my bachelor in physics and computer science. I really would like to participate as a GSoC-student of yours. I intend to write a proposal for the Boost.Devector project. But first I wanted to ask a few questions: 1) I didn't understand if devector is an intrusive container or it only has to use them? 2) What does this devector class should (exaclty) be capable to do? 3) Which methods are the most important to perform in O(1)? 4) I didn't used the boost-library very much in the past, is this a great problem for this project? Thanks for your time. Regards, Julian

2 1

[type-traits] compilation error in has_new_operator
by Andrey Torba 01 Apr '09

01 Apr '09

Hi All, After 52057-52061 commits the compilation error oocur: D:\c++\libs\boost_trunk\boost/type_traits/has_new_operator.hpp(40) : error C2039: 'nothrow_t' : is not a member of 'std' to reproduce try to compile: #include <boost/type_traits/has_new_operator.hpp> int main() { return 0; } Does it need #include <new>?

2 1