October 2010 - Boost - lists.boost.org

[fusion] tuple missing from sequence models?
by Mateusz Loskot 22 Oct '10

22 Oct '10

Hi, The boost::tuple seems to be missing (intentionally?) from the models of conforming to the forward sequence concept: http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/sequence/c… Though, the later chapter states it's adapted: http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/adapted.ht… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 2

[test] export bug or [graph] test mis-configured?
by Jim Bell 22 Oct '10

22 Oct '10

Boost.graph's stoer_wagner_test won't link on mingw32, with multiple definitions of various unit_test::test_case::... symbols. All symbols seem to be found in test/impl/unit_test_suite.ipp. Dynamic libraries for both boost_test_exec_monitor and boost_unit_test_framework are linked in. The compile has: -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 So is this graph test's compile or link wrong (but being forgiven on other platforms), or is test (notably unit_test_suite.ipp) not exporting symbols as it should (and that's being forgiven on other platforms)? The same problem (conceptually) is happening on msvc8, though it calls out more than just unit_test_suite.ipp.

1 0

[quickbook] Lists with paragraphs
by Edward Diener 21 Oct '10

21 Oct '10

Is there any way to specify a list with paragraphs embedded in each list item, such as a final result of: 1. Some data here. Some more data here. Maybe some code here. 2. Other data here More code here. In other words I can normally do this with lists by not separating lines which form individual paragraphs, but I want the spacing and paragraphs for each list item.

2 2

Unify multi_array and ublas matrix
by Gonsolo 21 Oct '10

21 Oct '10

Hi! Is there a plan to unify Boost's multi_arrays and ublas matrices? It seems to me those concepts are very similar. g

1 0

Re: [boost] [Backtrace] Any interest in portable stack trace?
by nimaca2001＠libero.it 21 Oct '10

21 Oct '10

> Linux, Solaris and Mac OS X have functions backtrace and backtrace_symbols > in libc: See: http://linux.die.net/man/3/backtrace > > Windows starting from XP has RtlCaptureBackTrace in kernel32.dll: > See http://msdn.microsoft.com/en-us/library/ff552119(VS.85).aspx > > So the rest is translate symbols, under Unixes I have dladdr and under Windows > dbghelp. How difficult would be a separate translation made with the map file instead of PDB file? (My main goal is to get the backtrace with raw addressed and traslate them 'at home' without spreading around rarely used stuff) Marco

1 0

Re: [boost] [1.45] Beta final schedule
by Jim Bell 20 Oct '10

20 Oct '10

>> > >> > Can we petition to hold up this release for some important bug fixes to >> > catch up to it? > This idea has some traction with me. ... > Ticket numbers? So far... https://svn.boost.org/trac/boost/ticket/4736 https://svn.boost.org/trac/boost/ticket/4698 https://svn.boost.org/trac/boost/ticket/4747 Less important, but would remove more yellow from the regression table... https://svn.boost.org/trac/boost/ticket/4735

7 9

svn.boost.org down?
by John Maddock 20 Oct '10

20 Oct '10

SVN seems to be working Ok, but something has taken Trac down, any ideas anyone? Cheers, John.

3 3

Thoughts for a GUI (Primitives) Library
by Gwenio 20 Oct '10

20 Oct '10

As it stands, neither Boost nor C++ has any support for GUI applications. Therefore I am suggesting a library that provides the bare minimum required to create a GUI application. My thoughts on what this library would contain are as follows: - Types for controls (contexts bound to the extent of their parent) and windows (contexts that remain separate from their parents). - An event handler class that is passed when controls and windows are created that contains all information needed to handle events for the new context. - Functions for generating events (if applicable) and (a) function(s) to initiate message handling (unless the event loop is run in its own thread like in Java). - Functions to access and manipulate the data of the contexts (size, position, z-order, ect). - Miscellaneous other types used for support (such as for screen positions). - A way to retrieve the native concept of a window/control. As you can see, there are no controls/widgets/ect defined, either from the library or using the native versions. Such things can be added later, if people can ever agree on how they should be implemented. It needs a lot of refining, but I believe this covers the *minimum* support that is needed for a GUI.

22 78

Re: [boost] [1.45] Beta final schedule
by Jim Bell 20 Oct '10

20 Oct '10

> Message: 5 > Date: Tue, 19 Oct 2010 15:09:50 -0700 > From: Eric Niebler <eric(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [1.45] Beta final schedule > Message-ID: <4CBE172E.90602(a)boostpro.com> > Content-Type: text/plain; charset=ISO-8859-1 > >> > >> > So far... >> > >> > https://svn.boost.org/trac/boost/ticket/4736 >> > https://svn.boost.org/trac/boost/ticket/4698 >> > https://svn.boost.org/trac/boost/ticket/4747 >> > >> > Less important, but would remove more yellow from the regression table... >> > https://svn.boost.org/trac/boost/ticket/4735 > Can you comment on whether these are regressions from previous releases? 1.44 had the first three, which is what (eventually) led me to this list (and pitching in to fix them).

2 1

Re: [boost] Understanding the test matrix
by Jim Bell 20 Oct '10

20 Oct '10

> The release test matrix seems to be telling me that there are many failures > on different platforms, and in fact > that there is no platform with no failures on all libraries, or libraries > with no failures on all platforms. We just > live with that, is that right? > > Do all the failures get fixed before an actual release is made, or noted in > the release notes? I think the original philosophy was that it should work on mainstream, modern compilers/platforms, but not necessarily on your old/outlier, and here's a matrix of what's been tested. I'm okay with that. Also, a single unexpected regression failure marks the whole library as fail/yellow on the main matrix. And something like serialization not linking cascades to several other libraries showing failed (e.g., date_time on mingw32). It should be that way, but it shakes the casual observer's confidence in all of boost. All this to say, maximizing the green on that regression matrix is worth the work, and worth holding up a release, IMHO. Also, many fixes are not as simple as just looking at the test results for a compiler/platform you have little experience with and can't test first-hand. (E.g., Ticket # 4736 -- it's clear the author was looking for the failure, but the only thing that made progress was my running it in gdb on that particular platform.)

1 0

Understanding the test matrix
by Robert Jones 20 Oct '10

20 Oct '10

Following on from some recent posts I had a look at the development area on the site, and would appreciate some clarification that I'm understanding it correctly. Firstly, I'm assuming that releases are made from area summarised under "Development -> Testing -> Release Summary" and development is carried out on trunk, so the release area is supposed to stable-ish and trunk not particularly? Is it correct that in some areas there are substantial divergence between trunk and release, sometimes reaching far back in time? The release test matrix seems to be telling me that there are many failures on different platforms, and in fact that there is no platform with no failures on all libraries, or libraries with no failures on all platforms. We just live with that, is that right? Do all the failures get fixed before an actual release is made, or noted in the release notes? Thx - Rob.

1 0

[system] Undocumented deprecated throws variable
by vicente.botet 20 Oct '10

20 Oct '10

Hi Beman, The documentation doesn't states explicitly that the throws variable is deprecated (see section "Deprecated names"). In addition the section "Semantics of throws object" explaining how this variable should be used must be rewritten to show the usage of the function throws(). Could this be changed for 1.45? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 2

Re: [boost] [1.45] Beta final schedule
by Jim Bell 19 Oct '10

19 Oct '10

Can we petition to hold up this release for some important bug fixes to catch up to it? I think gcc-mingw-4.x is an important platform (Qt SDK for Win32 ships with it), and it needs a few key ones.

2 1

Re: [boost] [exception] ostringstream like
by Fabien Castan 19 Oct '10

19 Oct '10

> No, I mean that if you do advanced string manipulation in the exception > itself, you may screw up, adn cause a bad_alloc beign thrown and masking > your own exception. Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error. > Just make your own, informative exception type deriving from logic_error. The problem is not really the kind of exception, but an easy way to create message with boost exception tag system. The idea is to create a new base class for tags allowing to use an ostringstream with tags, which is not possible. typedef ::boost::error_info<struct tag_message,std::ostringstream> message; This little class only remap operator+ call to operator<< on an internal ostringstream. typedef ::boost::error_info<struct tag_message,::boost::error_info_sstream> message; I use it in my code, but I ask here if we can hope to see such things in boost exception. I would prefer to use a standard boost object rather than a custom class.

4 3

[regex] Regex does not build current release branch with GCC
by Jeremiah Willcock 19 Oct '10

19 Oct '10

I am using GCC 4.1.2 (toolset "gcc"), and the current release branch produces the error: Performing configuration checks - has_icu builds : yes /dev/shm/release/tools/build/v2/build/feature.jam:485: in validate-value-string from module feature error: "msvc:<linkflags>delayimp.lib" is not a known value of feature <toolset> error: legal values: "gcc" (then a long backtrace) Removing the delayimp.lib line from libs/regex/build/Jamfile.v2 works around the problem but probably would cause problems on VC++. -- Jeremiah Willcock

1 0

[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