October 2010 - Boost - lists.preview.boost.org

[1.45] Beta final schedule
by Beman Dawes 19 Oct '10

19 Oct '10

Major changes should already have been merged to trunk. Last minute bug fixes should be merged to trunk by the end of Monday, October 25th. The beta will go out as soon after that as most release branch tests have cycled, typically three or four days later. --Beman

2 1

Re: [boost] What's so cool about Boost.MPI?
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 19-10-2010 14:59, Mathias Gaunard skrev: > On 18/10/10 23:41, David Abrahams wrote: >> >> Just wanted to call some attention to this article I wrote about >> Boost.MPI: >> >> http://daveabrahams.com/2010/09/03/whats-so-cool-about-boost-mpi/ >> >> I think it might be useful to link that from the Boost.MPI docs, too. > > While the library seems nice (it bridges serialization with MPI), I > don't really see anything in there that makes me think it's "so cool". > > So after reading it, I felt a bit like the question "What's so cool > about Boost.MPI?" remained unanswered. The semi-automatic, but very easy to maintain, way of creating/maintaining the MPI type maps (via Boost.Serialization), IIUC. -Thorsten

3 2

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0

[filesystem] temp_dir_path()
by Jeff Flinn 19 Oct '10

19 Oct '10

The need for portably obtaining 'the' temporary-directory-path has been brought up a few times(but never addressed AFAICT), and I am now in the need for this as well. Windows has the GetTempPath, which follows a specific order of looking for a temporary directory path. If GetTempPath returns 0, GetLastError provides a system error. Posix relies on getEnv("TMPDIR"), which returns 0 if the environment variable does not exist. The following windows and posix implementation would be in the detail namespace: BOOST_FILESYSTEM_DECL path temp_dir_path(system::error_code* ec) { # ifdef BOOST_POSIX_API const char* val = getenv("TMPDIR"); return val? path(val) : path(); # else // Windows std::vector<Path::value_type> buf(GetTempPathW(0, NULL)); if(GetTempPathW(buf.size(), &buf[0])) return path(buf.begin(), buf.end()); int errval(::GetLastError()); if (ec) ec->assign(errval, system_category()); return path() # endif } Questions: - should Posix return an empty path or an error when empty? - should Windows provide a more 'temp-path' centric error? - should both verify the path exists? - if the path does not exist should one be created? Thanks, Jeff

7 26

Fw: Interlibrary version cchecking
by Robert Ramey 19 Oct '10

19 Oct '10

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:<hsdfuq$prj$1(a)dough.gmane.org>... > Turns out that the idea of a single boost library deployment has come up a > couple of times here at BoostCon 2010. While preparing my presentation I > considered the problem of what would happen if one installed one library > which depended on an newer version of a different library than the user > already had installed. I actually woke up in the middle of the night > imagining someone would ask about that during my talk. I puzzled about it > for some time and the day before I found a way to address it - in my own > mind at least. It also seems that it turns out that there are tools that > can also manage this. > > It's not that I don't trust tools but I wear a belt AND suspenders. So I > would like a method which guarentees that when I build one library, I don't > accidently include code from a prerequisite library which is a version so > old that things won't work. I would also like to know that I'm not > accidently running with a DLL built with an old version. > > Basically each library includes a file "manifest.hpp". This get's included > when any header get's includes (once at most due to include guards). This > includes a static assert that checks that the prequiste libraries are of > sufficiently recent version that a dependent library (or user application) > requires. There is also a manifest.cpp file included in the library which > checks any prequiste DLLS. This would be an exheedingly small overhead to > avoid what could be an incredibly large headache. > > I just verified that the code compiles so at this point it's only an idea. > But it seems that some kind of check like this is un-avoidable of one want's > to deploy libraries as needed rather than as a monolithic distribution. > > FYI - no one asked me about this problem at my presentation. Add one more > confirmation of Murphy's law. > > Robert Ramey > > >

5 8

[accu london] Steve Love talks on Interface Versioning in C++
by Mateusz Loskot 19 Oct '10

19 Oct '10

Folks, I hope I'm not spamming and perhaps there are people on the list who are based in London and would find this talk interesting: What: Steve Love talks on Interface Versioning in C++ When: 21 October 2010 at 6.30pm for 7:00pm http://accu.org/index.php/accu_branches/accu_london/accu_london_oct_2010 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Accelerating algorithms with SIMD - Segmented iterators and alternatives
by Mathias Gaunard 19 Oct '10

19 Oct '10

Hi, I have, along with Joel Falcou, been looking a bit at how we can integrate SIMD into iterator-based algorithms to accelerate them. Unfortunately, there are a couple of issues. The basic idea is to provide a range adaptor that adapts of range of PODs, where N consecutive PODs are stored contiguously, into a range of vectors (or "packs") of those PODs of size N. Therefore, instead of: std::vector<float> tab(20); float sum = boost::accumulate(tab, 0); we can write something like: std::vector< float, simd::allocator<float> > tab(20); float sum = simd::sum( boost::accumulate( simd::packed_range<4>(tab), simd::zero_ ) ); Which does the same but using SSE instructions, adding four floats at a time, and typically providing a 4x speed-up. This can be applied to have the same result for any binary operation which is commutative and associative (which unfortunately isn't the case of many operations, but can still be useful). Here, however, it works because 1) the memory is well aligned thanks to the use of our custom allocator and 2) the size, 20, is a multiple of the pack size, 4. We'd be interested in providing a mechanism where we could also support ranges of data aligned at an arbitrary address and of an arbitrary size. The SSE would only be used in the middle, the borders being handled element per element. A first solution consists in padding the beginning and the end with zeroes. Say you have 1 2 3 4 5 6 7 with only 3 being aligned well enough for SSE usage. so we'd turn that into | 0 0 1 2 | 3 4 5 6 | 7 0 0 0 |. However, it is very important that the code to deal with borders does not affect the efficiency of the code in the middle. This is not possible with the normal iterator/range design. Our data is clearly cut into three segments: the beginning that is not aligned, the data that is rightly aligned and sized, and the data at the end that is not big enough to fill a whole pack. Therefore, segmented iterators could provide us with a solution to do this efficiently; but so could other solutions as well. Wouldn't it be better to be able to use the mechanism so that you could deal with the borders in an element-per-element way while you could deal with the middle bit in a vector-per-vector way? With C++ iterators, you pull data, but if we could use an iteration paradigm where you push data instead, such as calling a function object for each element, we could call an overloaded function that would be able to accept both a single element and a pack. Such a solution would also provide the speed benefits of segmented iterators, and all high-level standard algorithms can be expressed with this iteration paradigm just as well as with iterators. I have already suggested such an alternative to segmented iterators (where I had a few misconceptions about segmented iterators, I thought they broke compatibility, but they don't, they still maintain the legacy non-segmented interface) there: <http://thread.gmane.org/gmane.comp.lib.boost.user/61636/focus=61647>, with an example of how you could use that to iterate over a binary tree there: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=genera…> Converting from those things to a pair of iterators is possible through the use of a coroutine, as demonstrated in the example. I would like to have feedback on the general idea of providing tools to use SIMD with iterators and related algorithms, and ideas about whether there is sufficient interest in the alternative to iterators for me to develop them. The intent would be to submit both the alternative to iterators and the SIMD helpers to Boost.

24 120

boost utf-8 code conversion facet has security problems
by Patrick Horgan 18 Oct '10

18 Oct '10

I've been meaning to mention this for some time. The boost utf-8 code conversion facet implements an early spec of utf-8 that allows up to 6 byte representations but current specs, and security issues suggest it should only support up to four. See http://en.wikipedia.org/wiki/UTF-8 and in particular the section on invalid byte sequences. It also has some stuff wrong, like do_length() is supposed to only tell you length of valid code sequences, but the boost implementation doesn't check for validity. This has long since been superseded by newer specs that allow only 1-4 byte representations. The issue is that the longer representations let you alias characters, so if someone is filtering out certain chars for security reasons, for sql or http requests, for example, someone can bypass the filter by using a different representation of a character, and inject their naughty stuff just when you think you've got them stopped. In addition to no more 5 and 6 byte utf-8 chars, there are some other first and second byte codes that are forbidden because they would alias other characters. Current specs, see std 63 (also currently rfc 3629), and The Unicode Standard Version 5.2, specify how to correctly implement the conversion. I think that everything you need to know, however, to implement do_in() and do_length() correctly is in this table (notice that start and end of valid second byte range varies in different unicode code ranges): /* Table 3-7. Well-Formed UTF-8 Byte Sequences from version 5.2 of the Unicode Standard Code Points First Byte Second Byte Third Byte Fourth Byte U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF */ So, you have to do more checking, but it's still efficient. I have test code that checks all this. I'm willing to help in various ways. o I have an implementation of the utf-8 code conversion facet that implements do_in, do_out, and do_length that I did. You can have the source to jump start the fix. o I'm willing to make changes to the boost one and contribute a patch with a little guidance. o I'm willing to just figure that now that I've pointed it out, someone who owns this code will be motivated to fix it, it's not too hard. o Also willing to give you the test code to check with. Probably a lot different than how boost implements test code. o Willing to give peace a chance;) It should really be fixed. There's a lot of bad guys out there that know about these sorts of problems, plus, there aren't many open source implementations of utf-8 code conversion facets, so folks are likely to emulate/steal this. btw mine's freely available to anyone who requests it. wc -l * 232 codecvt_utf8_facet.cpp 29 codecvt_utf8_facet.hpp 14 Makefile 510 testcodecvt.cpp Funny the test code is twice the size of the code. Patrick

5 9

Fwd: [String algo] Breaking change between 1.41 and 1.44 in split
by Christophe Henry 18 Oct '10

18 Oct '10

As I got no answer on the user list, I try again. Is the library still maintained? ---------- Forwarded message ---------- From: Christophe Henry <christophe.j.henry(a)googlemail.com> Date: 2010/10/13 Subject: [String algo] Breaking change between 1.41 and 1.44 in split To: boost-users(a)lists.boost.org Hi, I noticed a breaking change in the split function when the input string is empty. Consider the following example: #include <string> #include <vector> #include <iostream> #include <boost/algorithm/string/split.hpp> #include <boost/algorithm/string/classification.hpp> int main() { std::vector<std::string> result; std::string empty_string; boost::algorithm::split( result, empty_string,boost::algorithm::is_any_of( "\t" ),boost::algorithm::token_compress_off); std::cout << "result size: " << result.size() << std::endl; return 0; } With boost 1.41 I get: result_size: 1 With 1.44 I get: result_size: 0 Meaning that splitting an empty string now has a new meaning. All I found to this subject was that 1 seems to be the correct answer (http://lists.boost.org/Archives/boost/2005/07/90266.php) Furthermore, there has been, according to the release notes, no change to string algo since the 1.41. This brings me to the question, before I start updating my code, is this change a design decision or an accident? Thanks, Christophe

2 2