- Boost - lists.boost.org

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

[review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 18 Oct '10

18 Oct '10

Dear all, Here follows the result of the result of Erwann Rogard's update to Boost.Assign: **************************** The update is not accepted **************************** This is not because the new functioanlity/interface was not seen as an improvement, but because Erwann has chosen to implement a full replacement (or Assign v2) based on the feedback he got during the review. The feedback meant that the new "update" would be much larger than what was present in the mini-review, and the new library should therefore be subject of its own full review. 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 would also like to thank the following people who participated in the mini-review: Christopher Jefferson Diederick C. Niehorster John Bytheway kind regards Thorsten, review manager

1 0

[pool] detail/mutex.hpp may include windows.h and pollute namespace with windows definitions.
by Paul Blampspied 18 Oct '10

18 Oct '10

I have been making an effort to write Windows independent code. In particular I avoid including windows.h in any of my headers (some implementation files include it). I have had a problem using Boost/pool as the mutex header includes windows.h (causing nameclashes with some of my existing code, which has always relied on the absence of windows.h). Possible inclusion of windows.h is documented in the section on mutex. My question is 'Is it really necessary or desirable ?'. Is there a Boost policy on the inclusion of OS specific headers which create a large number of declarations in the global namespace ? The section which uses windows.h is: #ifdef BOOST_WINDOWS class win32_mutex { private: ::CRITICAL_SECTION mtx; win32_mutex(const win32_mutex &); void operator=(const win32_mutex &); public: win32_mutex() { ::InitializeCriticalSection(&mtx); } ~win32_mutex() { ::DeleteCriticalSection(&mtx); } void lock() { ::EnterCriticalSection(&mtx); } void unlock() { ::LeaveCriticalSection(&mtx); } }; #endif // defined(BOOST_WINDOWS) I believe that the appropriate declarations of InitializeCriticalSection, DeleteCriticalSection, EnterCriticalSection, LeaveCriticalSection could be provided explicitly in this file and hence avoid including windows.h and the subsequent namespace 'pollution'. An alternative of using a Boost multithreading library is suggested in the documentation. This would be ideal, but my proposal would solve problem now, relatively effortlessly. PS. I did a quick edit and got it to work (at least on Vista). The change to the if-endif block is shown below. It could be done much better. # ifdef BOOST_WINDOWS //#include <windows.h> typedef char CRITICAL_SECTION[24]; //24 is sizeof(CRITICAL_SECTION) ! typedef CRITICAL_SECTION *LPCRITICAL_SECTION; #define WINAPI __stdcall extern void WINAPI InitializeCriticalSection( __out LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI DeleteCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI EnterCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI EnterCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); void WINAPI LeaveCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); # endif many regards, Paul

7 13

[property_tree] Copy constructor and assignment operator in xml_writer_settings class
by Mateusz Loskot 18 Oct '10

18 Oct '10

Hi, What is recommended or required policy regarding copy operations for types which consist of const data members, within Boost? I'm having problem with understanding why the xml_writer_settings class do not have the copying operations disabled. Perhaps it should be patched? Quick chat on the #boost IRC channel confirms it could be improved. I'm looking forward comments. [1] https://svn.boost.org/trac/boost/browser/trunk/boost/property_tree/detail/x… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

4 7

is_convertible_basic_impl and OpenMP - compile error
by Remi 18 Oct '10

18 Oct '10

Hi, I'd like to report nasty behaviour of boost when used inside OpenMP loops. In the following example compile error is generated under Visual 2008, if "default(none)" is used for OpenMP variable data sharing attribute clauses (which is the recommended choice). #define BOOST_ALL_NO_LIB 1 #include <boost/graph/adjacency_list.hpp> #include <omp.h> int main(int argc, char* argv[]) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> GraphType; typedef GraphType::adjacency_iterator GraphAdjacencyIterator; const unsigned int vertex_count( 20 ); typedef std::pair<int, int> EdgeType; std::vector<EdgeType> edges; const GraphType graph( edges.begin(), edges.end(), vertex_count, edges.size() ); int i( 0 ); #pragma omp parallel for schedule(static, 1) default(none) private(i) shared(vertex_count, graph) for ( i = 0; i < vertex_count; ++i ) { const std::pair<GraphAdjacencyIterator, GraphAdjacencyIterator> adjacent ( boost::adjacent_vertices(i, graph) ); } return 0; } "\boost\boost/type_traits/is_convertible.hpp(263) : error C3052: '_m_from' : variable doesn't appear in a data-sharing clause under a default(none) clause"

2 2

Version information for Boost library
by Edward Diener 18 Oct '10

18 Oct '10

Does Boost have any policy regarding the way version information should be attached to a library ?

4 6