September 2011 - Boost - lists.preview.boost.org

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7

Interest in simple unformatted binary stream I/O?
by Beman Dawes 04 Oct '11

04 Oct '11

There have been many requests on Boost and various C++ newsgroups for unformatted binary I/O. For example, in 2003 Neal Becker wrote: I wonder if anyone has code for implementing unformatted I/O? What I have in mind is for the simple case where the application that reads data knows the data types, so this is not as complicated as the general marshalling situation. This proposal provides a very simple solution that works with standard library input and output streams. The one caveat is that the stream must be opened with filemode std::ios_base::binary to avoid certain data values being treated as line endings. int main() { fstream f("binary_stream_example.dat", std::ios_base::trunc | std::ios_base::in | std::ios_base::out | std::ios_base::binary); int32_t x = 0x01020304; int32_t y = 0; f << bin(x); // write 4 bytes f.seekg(0); f >> bin(y); // read 4 bytes BOOST_ASSERT(x == y); return 0; } For docs, header, and example code, see http://mysite.verizon.net/beman/binary_stream/binary_stream.html http://mysite.verizon.net/beman/binary_stream/binary_stream.hpp http://mysite.verizon.net/beman/binary_stream/binary_stream_example.cpp Is there interest in this for Boost? It seems way too small and simple to be a whole library itself. Are there any ideas where it should live and what namespace it should be in? --Beman

15 26

[optional] Thoughts on disallowing assignment for wrapped references.
by Mostafa 04 Oct '11

04 Oct '11

Boost.Optional seems to really have a lot of potential for what I want to do, but one thing about it has been nagging me, specifically it's assignment semantics for wrapped references being different from the semantics of bare C++ references (see http://tinyurl.com/4yna643) Has/have the author(s) of the library or anyone considered disallowing assignment for Boost.Optional types that wrap references, and if so, what would the consequences of this entail? I rather disallow assignment in this case, then have what's basically a wrapper class behave partially differently than the type it's supposed to emulate. Thanks in advance, Mostafa

6 34

where to go to with libraries for a narrow problem domain?
by Thijs (M.A.) van den Berg 03 Oct '11

03 Oct '11

I'm part of a community that work in financial mathematics, and every now and then there are ideas to start library development on narrow sub-fields. A thing missing is a centralized place -exactly like boost- where people can submit and acquire high quality *narrow* C++ source code libraries. There are a lot of fragmented initiatives in mathematical finance: there is overlap between projects, quality may vary a lot, etc. The landscape resembles a bit the pre uBlas era for matrices. It there a place just like boost (good quality C++ source code libs with a large community) for narrow libraries? If not, wouldn't it be possible to create a subsection at boost for narrow libraries? Something like the Matlab toolboxes for C++ source libraries?

3 2

Is someone interested in container CompressedVector, a vector-like storage for integer types
by Alexander Bulovyatov 02 Oct '11

02 Oct '11

Hi! Assume you want an interface as for vector<unsigned int>, but know that elements have only N significant bits, say 17. In this case the container will save 46% memory compared to vector<unsigned int>. CompressedVector internally stores elements as a dynamic bitset (vector<size_t>) and uses bitshift ops to put/get significant bits into one or two size_t elements. It's similar to vector<bool> and dynamic_bitset, and has the same drawback, it's not a proper STL container. Anyway, the container is simple, efficient and quite fast. It will work best for very long arrays of indexes. Since its storage is continuous, it can also be used to speed up IO (load/store to disk, network transfers) acting as a very fast compression.

2 4

metatest interface update, better Boost.Test integration
by Ábel Sinkovics 02 Oct '11

02 Oct '11

Hi, Thank you for the feedback about my library so far. I've done changes to the interface of the metatest library (currently part of mpllibs - https://github.com/sabel83/mpllibs) The purpose of the changes was to improve compatibility with Boost.Test. They make it easy to embed assertions of compile-time predicates in runtime test functions. The result and pretty-printed reason of a compile-time predicate is represented by an object of type test_result (http://abel.web.elte.hu/mpllibs/metatest/test_result.html) at runtime. These objects can be built using a template function, test_result::build. It evaluates the predicate and does the pretty-printing. operator<< is overloaded for test_result, thus one can easily display these objects in output streams. This is useful for passing the results of compile-time tests to runtime unit testing frameworks. I've implemented the metaprogramming equivalent of the BOOST_<level>() macros as template functions (meta_<level>). One can use them the following way: meta_check< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE); meta_warn< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE, "Some message"); // ... I've used a template function instead of a macro to improve the error messages about syntax errors in the predicates. The template function takes a location (http://abel.web.elte.hu/mpllibs/metatest/location.html) object as argument and metatest provides a macro, MPLLIBS_HERE, that constructs a location object with the current filename:line values. The template functions call BOOST_<level>_MESSAGE. A disadvantage of this solution is that the error reports contain two filename:line locations: the location of BOOST_<level>_MESSAGE in the integration function and the location of MPLLIBS_HERE (which is the one the user will be interested in). I've added a new example demonstrating these integration functions. You can find it in libs/metatest/example/boost_test_assertion in the source tree. I've tested the new interface with the same three compilers I've been testing the libraries with (gcc 4.5, clang 2.8, Visual C++ 10). I'm happy to receive feedback about the new interface. I'm interested if people find it useful. Regards, Abel

2 3

[Review:Algorithms] My review of Boost.Algorithm
by dpxguard-boost＠yahoo.gr 01 Oct '11

01 Oct '11

Hello list, First of all I have to clarify that I have only studied the three search algorithms and I can only speak about this part of the library. Furthermore my review was by no means exhaustive, I have only emphasized in few things which I had the time to notice. However I have noticed at least two showstoppers, one in documentation of the search algorithms and the other in the design of the KMP algorithm. Hence my vote for now is "no". I personally believe that the search algorithms should not be accepted, unless these issues are addressed, (or unless I am proved wrong of course) although it would be undoubtedly a good idea to have such a library in Boost. Specifically in the design issue of the KMP algorithm I am willing to help if this becomes necessary. A. Documentation issue The three search algorithms of this library does not offer any additional functionality compared to the standard std::search of the STL. On the contrary these algorithms are less generic than std::search. Consequently the only single reason that will make a developer to choose one of them instead of the std::search can be their performance superiority. (In the most notable STL implementations std::search is implemented using straightforward (brute-force) searching.) However in the documentation I have not found anything (no benchmarks, measurements, etc) that would help the user of the library to understand how fast each algorithm is and in which situations it is advisable to use it. (I believe Phil Endecott has mentioned this issue as well) This is especially important because of the following reasons: - Boyer-Moore and Boyer-Moore-Horspool have identical average time complexity, hence it is not easy for the user to choose among them based on their complexities. - Although KMP has much better worst-case complexity than a typical std::search implementation, their average complexities are practically the same. - The straightforward (brute-force) sequence searching is known to frequently outperform some KMP implementations. For all these reasons I believe that some performance analysis and performance guidelines should be added to the documentation, before this library becomes a part of Boost. For example it would be very nice to have a graphical performance comparison of these three algorithms together with the std::search, in different pattern and alphabet sizes. B. Design issue The fact that the KMP implementation of this library requires random-access iterators for both the pattern and the corpus, seems like a major design drawback to me. I also believe that this drawback virtually cripples the usefulness of the algorithm, for reasons I have already mentioned in previous posts. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

2 1

[timer] Boost Timer Library Version 2
by Beman Dawes 30 Sep '11

30 Sep '11

Version 2 of Boost.Timer is about ready to move to trunk. The original version 1 timers are deprecated, but not changed in any way. Besides deciding to keep the version 2 timers in Boost.Timer, many suggestions and corrections from the "Boost.Timer replacement" thread have been applied. See http://lists.boost.org/Archives/boost/2011/09/185820.php The docs can be viewed at http://beman.github.com/timer/ The code is available at https://github.com/Beman/timer Thanks to all who posted comments, corrections, and suggestions in response to the original posting. Special thanks to Rob Stewart - many of his suggestions have been incorporated - and to Vicente Botet for his work on Boost.Chrono which now is used to implement much higher resolution for wall-clock time. While additional comments are always welcome, unless someone comes up with a showstopper I'm planning to move Version 2 to trunk and get on with other projects. --Beman

3 15

Re: [boost] property tree find no match for 'operator=='
by Ivan Le Lann 30 Sep '11

30 Sep '11

----- "Bernd Prager" <bernd(a)prager.ws> a écrit : > All, > > This is likely to be a silly question. > I am trying to check for the existence of a value in a property tree. > > Reading the docs I assumed the easiest way would be: > > namespace pt = boost::property_tree; > static pt::ptree pt; > > bool has(const std::string key) { > if (pt.find(key) == pt.end()) return false; // (1) > return true; > } > > The compiler complains about "error: no match for 'operator=='" in > line > (1) though. > What am I missing? > For your problem, the two iterators are not of the same type. Don't know the exact reason, but I know that ptree uses multi_index. Might be related. Anyway : - you have a get_optional() method. - you can try replacing end() with not_found() Regards, Ivan

1 0

property tree find no match for 'operator=='
by Bernd Prager 30 Sep '11

30 Sep '11

All, This is likely to be a silly question. I am trying to check for the existence of a value in a property tree. Reading the docs I assumed the easiest way would be: namespace pt = boost::property_tree; static pt::ptree pt; bool has(const std::string key) { if (pt.find(key) == pt.end()) return false; // (1) return true; } The compiler complains about "error: no match for 'operator=='" in line (1) though. What am I missing? Thank you for any help, -- Bernd

2 1