September 2007 - Boost - lists.boost.org

1.34.1 support?
by Vladimir Prus 03 Sep '07

03 Sep '07

What is our policy regarding bugfixes for 1.34.1? For example, I know of a couple of bugs in build system -- one that makes it impossible to build 1.34.1 on cygwin, and another is that "define=FOO" on command line does not work. First was fixed even before 1.34.1, but not included in release, second was just fixed. Now, it's being a month since 1.34.1, and it does not seem like 1.35 is going to be released very soon, so how do we most conveniently provide such fixes to users? Having to manually grab those from trunk is not very nice. - Volodya

3 2

no svn:ignore bin.v2 and stage ??
by Frank Birbacher 02 Sep '07

02 Sep '07

Hi! I'm quite new to the boost svn and I just wonder why the trunk does not have its svn:ignore property set to the build-dir of bjam. I expected the property to list "bin.v2" and "stage". Is there a reason to why the property svn:ignore is empty on the trunk? Frank

1 0

Help wanted: porting/testing the Math Toolkit to MacOS X
by John Maddock 02 Sep '07

02 Sep '07

Any MacOS X experts willing to run some tests on the Math Toolkit, and/or help track down any porting issues? The latest code is in the sandbox under "math_toolkit", last time the tests were run on that platform there were still some unresolved issues with the Mac's strange long double type to be resolved... I'd like to get these nailed down if possible before we do a first post-review release. Many thanks, John Maddock.

5 16

what's the relationship between these two files?
by Leo Jay 02 Sep '07

02 Sep '07

i built filesystem library by myself, and two files bjam generated confused me: libboost_filesystem-gcc40.so libboost_filesystem-gcc40-1_34_1.so.1.34.1.so what's the relationship between these files? why the latter one has such a strange name? thanks. -- Best Regards, Leo Jay

1 0

[Filesystem] Native Pathname Format
by Edward Diener 02 Sep '07

02 Sep '07

I can not determine from the Filesystem documentation, nor the reference documentation which comes with it, what is the acceptable syntax for the native pathname format. It appears one must start the native pathname format with //: in order for it to be recognized, but I can not tell from what appears to me to be very confusing documentation whether this is so for the Boost Fileystem implementation. This would mean, let's say under Windows, that "c:\afile" would not be recognized but that "//:c:\afile" would be recognized, as far as I can make out from the documentation. It sure is confusing IMO. Can anybody clarify how this works for Filesystem and/or where there is a clear explanation of how it works in the documentation ?

2 2

Macro/Typedef for the biggest integer for template parameters
by Daryle Walker 01 Sep '07

01 Sep '07

We've talked about this problem off and on for years now, and I'm wondering if we can finally solve it. Many compilers supply built-in integer types beyond (unsigned) long int, but someone told me that there's no guarantee that those super-long types are suitable for use in a value-based template parameter. I'm wondering if we can develop typedefs, maybe in "boost/cstdint.hpp", that describe the largest suitable signed and unsigned built-in integer types that can be used as value-based template parameters. On basically-standard compilers, this would be "unsigned long" and "long". I'm thinking that we could default to boost::[u]intmax_t, and #case it for particular compilers after they choke on not being able to use "long long" or "__int64_t" in a template. (We could test in advance to minimize hardship.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Linearizing type list creation without macros
by Marco Costalba 01 Sep '07

01 Sep '07

Form Alexandrescu "Modern C++...", a type list is defined as template<class T, class U> struct TL { typedef T head; typedef U tail; }; A lot of interesting stuff can be made with, please refer to the book for reference. A problem is the initialization, as the author says: "A Plethora of macros that transform recursion into simple enumeration..." Something like: #define TL_1(a) TL<a, NullType > #define TL_2(a,b) TL<a, TL_1(b) > #define TL_3(a,b,c) TL<a, TL_2(b,c) > #define TL_4(a,b,c,d) TL<a, TL_3(b,c,d) > #define TL_5(a,b,c,d,e) TL<a, TL_4(b,c,d,e) > #define TL_6(a,b,c,d,e,f) TL<a, TL_5(b,c,d,e,f) > So that it is possible to say: TL_3(int, double, char*) and get the corresponding type list. I think it is possible to avoid the macros: struct E {}; template<class T1 = E, class T2 = E, class T3 = E, class T4 = E, class T5 = E, class T6 = E, class T7 = E> struct TLCreator { typedef TL<T1, typename TLCreator<T2,T3,T4,T5,T6,T7,E>::MyTL> MyTL; }; template<> struct TLCreator<E, E, E, E, E, E, E> { typedef E MyTL; }; Now you can say: TLCreator<int, double, char*>::MyTL instead of using a macro. Following little drivers shows it works. First define a type list length calculator, as explained by Alexandrescu: /* type list length */ template<class TL> struct Length; template<> struct Length<E> { enum{ value = 0 }; }; template<class T, class U> struct Length<TL<T,U> > { enum{ value = 1 + Length<U>::value }; }; Then test putting in main() the following int m1 = Length< TLCreator<int>::MyTL >::value; int m2 = Length< TLCreator<int, double>::MyTL >::value; int m3 = Length< TLCreator<int, double, std::string>::MyTL >::value; int m4 = Length< TLCreator<int, double, std::string, char>::MyTL >::value; std::cout << "\n" << m1 << ", " << m2 << ", " << m3 << ", " << m4 << "\n"; And you get what you would expect! I don't know if this is a known result. But it seems very powerful, indeed you can do a lot of things following the previous schema. If it is not already known I can post more example of the use of the above "template parameters iteration" schema. Thanks for your attention Marco

3 2

A need for a COOKBOOK
by dhruva 01 Sep '07

01 Sep '07

Hi, I am trying to get more into BOOST than what I am using currently (which is quite minimal compared to what BOOST has to offer these days) and which does not include a whole lot of new things that have got into BOOST. Are there any BOOST professionals willing to come up with a COOKBOOK for using BOOST libraries? The book "Beyond the C++ Standard Library: An Introduction to Boost" has a decent coverage but is quite dated compared to the leap BOOST library suite has seen in the recent days. As a user of BOOST, I request someone with good knowledge to come up with a COOKBOOK (like the PERL/PYTHON cookbook) for the benefit for BOOST users. It could be modeled along the PYTHON COOKBOOK. Activestate has a site to submit recipes and those are taken up, polished and edited into a nice book. with best regards, dhruva -- Dhruva Krishnamurthy Contents reflect my personal views only!

1 0

[Boost.MPI] How to use with processes on different machines?
by Manuel Jung 01 Sep '07

01 Sep '07

Hi, I would like to know, how i can use Boost.MPI for IPC between different PCs. It is described in the introduction: "Unlike communication in threaded environments or using a shared-memory library, Boost.MPI processes can be spread across many different machines, possibly with different operating systems and underlying architectures." Is there an example, how its done? I cant find one. Or isn't implemented yet? Kind Regards Manuel Jung

2 2

[constrained-value] additional features
by Martin Dowie 01 Sep '07

01 Sep '07

I've managed to download this now (thanks!) and I've played about with added support for floats/doubles. I'd also quite like the idea of being able to retrieve the range of a constrained value so that I can use them in other more constrained values - e.g. degrees in a circle => [0, 359] but sometimes only half a circle is appropriate [0, 179]. I'd like to be able to model this, e.g. typedef bounded_int<int, 0, 359>::type degrees_in_circle; typedef bounded_int<int, degrees_in_circle::first, 180>::type degrees_in_semicircle; That's a bit contrived but hopefully you get my drift. Ada uses 'First and 'Last to get this sort of value and I've always found these sort of attributes (or 'traits') very useful. Cheers -- Martin

2 1