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

Intel compiler and Boost libraries
by Edward Diener 20 Aug '11

20 Aug '11

I normally do not mind paying for software that much but because of the tight economic times for myself I am a bit loth to pay for a version of the Intel C++ compiler, which is not exactly cheap, in order to just test out my Boost libraries. Ordinarily I can use gcc in Linux and Windows, clang on Linux, or VC++ on Windows. But I am aware that the more compilers I can test my libraries with, the better off my library will be and in the review of my TTI library one of the points made is that I need to test it and guarantee that it will work on a wider variety of C++ compilers. I am wondering how others have come by their copies of Intel C++ ? Have you bought it, have you gotten it on some sort of academic pricing, have you acquired a license as part of your job, does Intel offer an inexpensive or free version of their compiler for C++ experts like Boost developers who are helping to test their compiler against the most rigorous C++ code as Boost libraries usually are, or what is the situation for others who test their libraries using Intel C++ ? I realize there is a 30-day free trial but after that 30 days one can not use the compiler for a particular OS without having a valid license for it.

3 3

Re: [boost] [Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by Ion Gaztañaga 19 Aug '11

19 Aug '11

El 19/08/2011 23:55, Dave Abrahams escribió: > Find the performance tests being used by clang's libc++ and try those? Thanks, is that code license-compatible with Boost license? Best, Ion

1 0

[UUID] seed_rng.hpp contains invalid forward declaration of random_device
by Johan Lindvall 19 Aug '11

19 Aug '11

The following fails to compile with 1.47.0: #include <boost/uuid/seed_rng.hpp> #include <boost/random/random_device.hpp> It used to work with 1.46.1 (using nondet_random.hpp) Filed as https://svn.boost.org/trac/boost/ticket/5794 -- /Johan.

1 0

[random] uniform_smallint
by Agustín K-ballo Bergé 19 Aug '11

19 Aug '11

boost::uniform_smallint<> distribution defaults its min and max constructor arguments to 0 and 9 respectively. While arbitrary, this may make sense for default constructed distributions. However, its easy to trigger an assert at runtime by calling its constructor with a single value (min > 9). Could this constructor be splitted into a default constructor and one that takes *both* min and max? I tried to check whether the standard mandates this, but couldn't find the FDIS online anymore (on a separate note, anyone knows where to find it?). Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

1 0

[gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Soares Chen Ruo Fei 19 Aug '11

19 Aug '11

Hi all, A while ago I gave some previews of my Unicode String Adapter library to the boost community but I didn't receive much feedback. Now that GSoC is ending I'd like you all to take a look at my project again and provide feedback on the usefulness of the library. Following are the links to my project repository and documentation: GitHub repository: https://github.com/crf00/boost.ustr Documentation: http://crf.scriptmatrix.net/ustr/index.html Recently there was some threads in the mailing list mentioning about Unicode issues and forcing the use of UTF-8 encoding in std::string again. I feel certain that few of the key people involving in the debates should have at least read my project proposal before and understand what Boost.Ustr was trying to achieve, however it seems like my approach is not much favored by anyone. So here I'd also like to know from these people why my approach on using Unicode string adapter is not the best way to solve the Unicode problem in C++. I understand that the requirement to alter existing APIs might be the biggest barrier to make Boost.Ustr adopted by everyone, but I think here is the key question: if you have the chance to go back in time and restart your project from scratch, are you willing to use Boost.Ustr in your library APIs and do you think that it could have solved the Unicode problems you're having right now? Thanks. Best Regards, Soares Chen

14 61

Re: [boost] New version of Boost.Algorithm (proposed) in the vault
by TONGARI 17 Aug '11

17 Aug '11

2011/8/18 Marshall Clow <mclow.lists(a)gmail.com> > > On Aug 17, 2011, at 9:28 AM, TONGARI wrote: > > > 2011/4/19 Marshall Clow <mclow.lists(a)gmail.com> > > > >> < > >> > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.… > >>> > >> > >> Changes since -008: > >> > >> * Better documentation all around - including doxygen. > >> * Fixed typo-style bugs in all.hpp, and added tests to make sure they > stay > >> dead. > >> * Better comments in clamp.hpp, and better tests. > >> * The search algorithms now deal correctly with zero-length patterns and > >> corpuses, and have tests for that. > >> * The search algorithms now have tests for the compile-time assertions. > >> * MSVC 10 compatibility > >> > >> Please download, try it out, and let me know! > >> > > > > I was trying to use KMP and got some errors: > > * No CHAR_BIT declared. > > * template boost::algorithm::knuth_morris_pratt does not accept plain > > pointer type. > > What compiler and version (and OS)? > g++4.5.2/MinGW, on XP SP3, compiled with c++0x enabled. But I don't think it's compiler specific, I can locate the errors...

2 1

[filesystem] Documentation error?
by John Maddock 17 Aug '11

17 Aug '11

The filesystem docs mention: #include <boost/filesystem> But of course no such file exists. John.

1 0

[vmd] Variadic Macro Data library updated to version 1.5 in the sandbox
by Edward Diener 17 Aug '11

17 Aug '11

I have updated the variadic_macro_data library in the sandbox 'variadic_macro_data' directory to version 1.5. The variadic_macro_data library, or VMD for short. adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. The changes in this version are: 1) The library now operates in one of two modes. The 'native' mode, which is the default, uses the library's own coding for various macros. The 'pplib' mode uses the code of the Boost PP library on the trunk for various macros. The documentation gives the equivalent Boost PP trunk macros for VMD macros. 2) Individual header files can be included instead of the vmd.hpp header file. 3) Macros have been added for detecting and removing beginning parens. 4) A macro has been added for testing for emptiness using variadic macros. 5) Macros have been added for verifying Boost PP data types. 6) Added control macros for controlling the variadic macro availability, mode, and data verification. There is a readme.txt in the top-level sandbox directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.3.3, 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1, 4.6.0 and VC++ 8.0, 9.0, 10.0. It should also work with other compilers which support variadic macros. Questions, comments, suggestions, and bug reports are all welcome.

1 1

New version of Boost.Algorithm (proposed) in the vault
by Marshall Clow 17 Aug '11

17 Aug '11

<http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…> Changes since -008: * Better documentation all around - including doxygen. * Fixed typo-style bugs in all.hpp, and added tests to make sure they stay dead. * Better comments in clamp.hpp, and better tests. * The search algorithms now deal correctly with zero-length patterns and corpuses, and have tests for that. * The search algorithms now have tests for the compile-time assertions. * MSVC 10 compatibility Please download, try it out, and let me know! Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 2

Help tracking down a GCC codegen issue
by Matt Fischer 17 Aug '11

17 Aug '11

Hi all. I'm trying to compile boost under GCC for ARM, and am running into an instance of some bad assembly code being generated. The actual problem seems likely to be an issue with GCC itself, or possibly some kind of modification that the vendor, CodeSourcery, made to it. I've contacted them about the problem [1], but in order to diagnose it, they need a reduced test case that doesn't involve the boost library. I'm attempting to dig out the relevant code and use it to construct a test case, but I'm having some trouble navigating the boost codebase, and was wondering if anybody could provide some assistance. A program that illustrates the problem is the following (compiled on Windows, using GCC 4.5.2 with Boost 1.40): ----------------------------------------------------------- #include <boost/signal.hpp> bool func() { return false; } int main(int argc, char *argv[]) { boost::signal<bool ()> sig; sig.connect(func); bool result = sig(); } ----------------------------------------------------------- Normally this works fine, but if I compile for GCC under ARM with -mthumb -Os, one of the instantiated template functions has some bogus assembly code in it (prepare for wall-of-text): 00000000 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int (boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)>: 0: b537 push {r0, r1, r2, r4, r5, lr} 2: 1c05 adds r5, r0, #0 4: ac01 add r4, sp, #4 6: 1c29 adds r1, r5, #0 8: 1c20 adds r0, r4, #0 a: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> e: 1c28 adds r0, r5, #0 10: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> 14: 7820 ldrb r0, [r4, #0] 16: bc37 pop {r0, r1, r2, r4, r5} 18: bc02 pop {r1} 1a: 4708 bx r1 The error is on line 14 and 16: we load up the return value from this function (a bool) into r0 in preparation for return, but then turn around and pop off a bunch of values from the stack, placing one into r0, which overwrites the return value and causes garbage to be returned to the caller. If I can produce a standalone test function that illustrates the problem, the compiler folks can probably figure it out. I've been trying to make one, but all of the template magic is making it difficult for me to track down where this function is coming from in the source code, and what a suitable standalone equivalent might be. Is there anybody who is familiar with all of the slot code that might be able to help out with this? Thanks, Matt 1. Original posting at http://www.codesourcery.com/archives/arm-gnu/msg04302.html

1 0