July 2010 - Boost - lists.boost.org

[serialization] patching 1.43 for the version numbering issue
by Ryan Gallagher 29 Jul '10

29 Jul '10

Hi Robert, As we were discussing the other day, I'd like to just patch my 1.43 release to fix the serialization library versioning issue so that my archives created with it won't need to have the utility run on them for 1.44+ to understand them. I just want to verify with you that changing the version number in serialization/src/basic_archive.cpp is all that's needed. In your recent trunk change you increased the version for 1.44 to '8': https://svn.boost.org/trac/boost/changeset/64157 However, the 1.43 source seems to have version '7' already. I must be missing something as I don't see how binary archived were using library version '6' for 1.42/43. Thanks, -Ryan

4 7

SGI rope in boost?
by Yakov Galka 28 Jul '10

28 Jul '10

Hello all, I can't use SGI's STL for several reasons: * It's incompatible with the standard library implementation shipped with my compiler (MVS). * Extracting only ropes is a headache, there are too much dependencies. * Unacceptable license. Were there any discussions about implementing ropes in boost? Yakov

4 4

Fisher Exact test in boost ?
by Jean-Baptiste Cazier 28 Jul '10

28 Jul '10

Dear all, I am brand new to this mailing list so I apologize in advance for the naivety of my request. I am looking for an implementation of the Fisher exact test in C/C++, and was somehow hoping to find one in boost. I have looked at the documentation of boost and and found many statistical tools, but not the one I am looking for. The closest I got was a discussion in the mailing archive in 2008 on the use of the hypergeometric distribution to perform such implementation Was any progress made since then ? Could I now get the cdf, pmf and sf from an hypergeometric distribution ? or even better a Fisher exact test directly ? Any help will be welcome Thanks Cheers ! Jean-Baptiste

2 4

Re: [boost] [GIL] bits64
by fabien.castan＠free.fr 28 Jul '10

28 Jul '10

> I have been promoting the idea of people contributing any new functionality > of GIL that they find useful by creating a GIL extension that is not > originally in boost. This allows for an opportunity for people to try their > code, flesh out some bugs, suggest changes to the design, etc. We can also > use this as a mechanism to see how popular certain functionality is and use > that to decide which functionality will make it into boost. That way, by the > time it is proposed for inclusion into boost, the code will be more solid. Yes, I have seen it, I use it, and hope to propose new things one day. But adding typedefs is not adding new functionalities. It's the normal usage of the library. If there is a bug here, it's a bug in gil itself not in the added code... So I define it in my code and use it without problem. Maybe we can add those typedefs at least in gil extensions ? If you want I can send you the code.

1 0

[context] user-context switching
by Oliver Kowalke 27 Jul '10

27 Jul '10

I've moved the context switching code from boost.fiber into a new lib - boost.context (uploaded to boost vault). The lib contains assembler for some platforms: i386, x86_64 and arm (aapcs-linux only). It could be used for code implementing cooperative scheduling (such as boost.coroutine and boost.fiber). Oliver

1 0

[gsoc][RFC] Pointer Plus Bits
by Brian Bartman 27 Jul '10

27 Jul '10

Hello, I previously sent out an email to the list about a pointer plus bits like data structure and received some feedback about a pointer plus bits data structure. After taking into consideration all of the different points of view, comments and concerns voiced by the Boost community I have implemented an extension to my bitfield_tuple which allows the user to easily store parts of a pointer and use the extra bits for storage. Here is a basic overview of the bitfield_tuple: Its a tuple like data structure which stores bitfields instead of whole types inside of single tuple. This allows the user to skirt packing limitations of structs and classes in C++ and create bitfields over the storage type of their choice OR leave that decision up to the data structure (the behavior for selecting the storage type is to select the smallest possible unsigned integral type which will hold the all of the bitfields). example of basic bitfield_tuple declaration. #include<boost/integer/bitfield_tuple.hpp> struct red; struct green; struct blue; using namespace boost; using namespace boost::bitfields; typedef bitfield_tuple< member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5> > rgb565_t; The bitfield_tuple takes ordered named template parameters (In the case of the storage type order is ignored. IE no matter where you put the storage< type > template the ending result will be the same). the bitfield_tuple supports the following template named template parameters (all of the templates which follow are located within the boost::bitfields namespace): bit_align< std::size_t> -> increases the offset of the next field to an offset which is divisible by the supplied value unless the current index is divisible by the supplied value then there is no increase. filler<std::size_t> -> bits to be skipped. member<typename, typename, std::size_t> -> this is a basic bitfield parameters it takes are the type the bitfield is to return, a naming type and the width of a bitfield flag<typename> -> boolean version of member. storage<typename> -> uses the supplied type for internal storage. pointer<typename, typename, typename> -> NEW described below. Pointer Member Information: The pointer member takes three template parameters. 1) The type you would like to make a pointer to. 2) The name which can be used (instead of an index, index is also still available to use) to access the pointer. 3) This is an integral_constant or integral_constant like type which is used to make a mask over the value bits of the pointer. This has a default value to leave the last two bits open. You can use leading or ending bits of the pointer for storage by supplying a different mask. Reasoning behind allowing for leading storage bits. There are some systems which do low address allocations and then store values within the higher part of the address. While this is much more rare then the use case of stuffing two bits inside of the end of a pointer I felt that it would be best to provide a way to actually do this. Reasoning behind restricting the mask to an integral_constant or integral_constant like type. The intent for this is to associate a non deduced type with the mask itself, however if people feel better simply using hex to specify the mask I could change the behavior to do that. There are mask creation utilities which can be used to create the mask from a higher level the simply supplying hex. Here are some examples of how to declare a bitfield_tuple with a pointer member: #include <boost/integer/bitfield_tuple.hpp> #include <boost/assert.hpp> using namespace boost; using namespace boost::bitfields; struct ptr; struct color; struct i1; struct i2; typedef bitfield_tuple< pointer<int, ptr> > ptr_1; typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> > ptr_plus_two_bools; typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> > ptr_plus_two_bit_color; int main() { ptr_1 p1; int i = 10; p1.get<0>() = &i; BOOST_ASSERT(*p1.get<ptr>() == 10); ptr_plus_two_bools p2; p2.get<ptr>() = &i; ptr.get<b1>() = true; ptr.get<2>() = false; ptr_plus_two_bit_color p3; p3.get<ptr>() = &i; p3.get<color>() = 3; return 0; } The pointer does NOT have to be the first parameter of the bitfield tuple one can simply place things in front of the the pointer and the value mask of the pointer will not be affected. The only thing which is different when this is done is the offset of the pointer within the bitfield_tuples storage, this only changes the location of the bitfield where the pointer is actually being stored. That being said you will always receive the value bits of the pointer in the exact same way they were taken from inside the pointer. -- thanks, Brian Bartman

4 16

Question about boost license
by Marc Elias 27 Jul '10

27 Jul '10

Hello, Allow me to introduce myself, my name is Marc and I would like to use the boost libraries to perform some work on a software with commercial profit. I have some questions about Boost License Policy I would like to know. As I can read in your webpage, most of the Boost libraries are under a single license that allows me to use the libraries for commercial purposes following the instructions you provide in the webpage. You also inform in the webpage that some libraries are under their own licenses. I would like to know, if it's possible, which libraries are under particular licenses and which are these specific licenses. Is it possible to have this information? Thanks a lot for your help. MARC _________________________________________________________________ Accede a tu Hotmail en un solo clic ¡Descárgate Internet Explorer 8 y empieza a disfrutar de todas las ventajas! http://www.ayudartepodria.com/

5 4

Review request: XInt
by Chad Nelson 26 Jul '10

26 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am officially requesting a formal review for the Extended Integer library (a arbitrary-length integer math library). The final review version is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). Thanks to everyone who offered suggestions and comments. It's a lot better for them, and likely a lot more useful. Here's hoping for a positive and speedy review. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw9BTYACgkQp9x9jeZ9/wQX+gCgi1N29anc96B6EX+pZ5rgrvyu d8wAnjfHyu5JQVMVu6BFQPtYExG3SbZR =25L3 -----END PGP SIGNATURE-----

2 3

New name of bjam.exe
by Vladimir Prus 26 Jul '10

26 Jul '10

Boosters, I am sure that most of you got accustomed to typing "bjam" in console whenever you want to build things. This name is old, and derives from a tool named "jam", which is even older (around for maybe 20 years). However, this name is probably no longer good. First, having a single project be identified by both "Boost.Build" and "bjam" names proves inconveninent from "marketing" and conveninence standpoints, to the point where many users try to read documentation for Boost.Jam, don't find anything there, and become upset. Second, users get the idea that Boost.Build is somehow related to "Classic Jam", which is not true. For those reasons, Rene and I have decided that "bjam.exe" should go. We're thinking about naming the executable simply "build.exe", since no other build tool bothered to take it. Does anybody have comments, or better suggestions? Thanks, Volodya

39 62

[1.44] Snapshot available
by Beman Dawes 26 Jul '10

26 Jul '10

The daily release snapshots are working fully again. That's important because the releases are based on the snapshots. See http://boost.cowic.de/rc/ --Beman

1 0