- Boost - lists.boost.org

[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

How to use BCP
by William Voorhees 17 Aug '11

17 Aug '11

I'm updating a small C program to take in a options from either environment variables, or a config file and having long heard of boost as a great resource decided to give the program_options module a try. Since the utility is small and I don't have any current plans for other boost functionality it doesn't make sense to include the full BOOST library, so I tried to use bcp to get only the files I'm interested in. I was able to get a subset of boost code that I should be able to use with bcp, however I don't know how to compile the program_options library for linking in my code. >From a bit of googling it looks like bjam is the build tool, but it doesn't seem to be included with the subset of files I have. How would I go about incorporating boost so that all of the necessary source and associated utilities are included for an end user to build from. I should be able to issue a series of simple commands (looks like ./bootstrap.sh and make) to build and install my library with statically linked in boost. -Will Voorhees

3 5

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

17 Aug '11

El 17/08/2011 12:20, Diederick C. Niehorster escribió: > Some performance tests might be nice here too (and the code for > generating them should be incorporated in the distribution), comparing > to std:: libraries shipped with the popular compilers. It'll help sell > your library and it'll serve as a nice benchmark later as vendors > update their standard library implementations. At least, I'd be > interested in such information and if test code is avaiable, I could > easily run the testcases myself. This is a good idea, but it'd require a huge amount of work if we think about an extensive benchamark framework. Maybe some basic tests?

1 0

[Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by John Maddock 17 Aug '11

17 Aug '11

The review of the containers library by Ion Gaztanaga starts today, to summarize the library: "Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. In short, what does Boost.Container offer? * Move semantics are implemented, including move emulation for pre-C++0x compilers. * New advanced features (e.g. placement insertion, recursive containers) are present. * Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). * The library offers new useful containers: o flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements for standard associative containers but more memory friendly and with faster searches. o stable_vector: a std::list and std::vector hybrid with random-access iterators that offers iterator stability in insertions and erasures. o slist: the classic pre-standard singly linked list container." Documentation from the library may be viewed online here: file:///M:/data/boost/sandbox/move/libs/container/doc/html/index.html The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Review comments might like to answer the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Regards, John Maddock.

10 18

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 17 Aug '11

17 Aug '11

The containers library review is now officially over. However, there are still a few drips a drabs of reviews coming in.... are there any more still pending? Thanks, John.

3 2

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Stewart, Robert 16 Aug '11

16 Aug '11

Yakov Galka wrote: > On Fri, Aug 12, 2011 at 15:04, Matus Chochlik > <chochlik(a)gmail.com> wrote: > > On Fri, Aug 12, 2011 at 1:08 PM, Yakov Galka > > <ybungalobill(a)gmail.com> rote: > > > On Fri, Aug 12, 2011 at 12:00, Matus Chochlik > > > <chochlik(a)gmail.com> wrote: > > >> On Fri, Aug 12, 2011 at 9:57 AM, Daniel James > > >> <dnljms(a)gmail.com> wrote: > > >> > On 11 August 2011 12:57, Artyom Beilis > > >> > <artyomtnk(a)yahoo.com> wrote: > > > >> // by default expect UTF8 > > >> text(const std::string& str) > > >> { > > >> assert(is_utf8(str.begin(), str.end())); > > >> store(str); > > >> } > > > > > > What you are doing is, in fact, forcing the assumed > > > encoding of std::string to UTF-8. You just said you > > > think it's a bad idea. > > > > No, I'm proposing to implement a *new* class that > > will store the text in UTF8 encoding and if during > > the construction no encoding is specified, then it > > is assumed that the particular std::string is already > > in UTF8. > > > This is *very* different from imposing > > an encoding on std::string which is already > > used in many situations with other encodings. > > i.e. my approach does not break any existing code. > > Sorry, your arguments start to look non-constructive to me. > Correct me where I'm wrong in the following reasoning. > > (1) You object to UTF-8 strings in boost interface because > someone may pass something other than UTF-8 there and it's > going to be undetected at compile time: > > namespace boost { void func(const std::string& a); } // UTF-8 > boost::func(non_utf_string); //oops > > You're proposing a `text` class that is meant to somehow > overcome this problem. So you change the boost interface > to accept `text` but user code is left unchanged...: > > namespace boost { void func(const text& a); } > boost::func(non_utf_string); //oops, the std::string default > constructor is called. > > Yes, you can make this constructor explicit, so the above code > stops compiling and the user must write explicitly: > boost::func(text(non_utf_string)); > > But then there is nothing in your proposal that makes > std::string utf-8 encoded by 'default'. Default == implicit. As soon as the client did a cast, the client made the claim that non_utf_string met the requirements of the text class' constructor. The problem is that of the client misusing the class by an ill-advised cast. What's more, I think Soares indicated a debug-build validation that the argument indeed was UTF-8. I don't see a problem in that design, once the constructor is explicit. > > Besided it does not harm you in any way > > It does. I already use UTF-8 for all my strings, even on > windows, and I don't want the code-bloat of all these > conversions (even if they're no-ops). What code bloat do you get from NOPs? Sure, there is more compilation time for the compiler to parse the text code and then for the optimizer to streamline it into a NOP, but even that is very likely negligible. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

[Review] Lockfree review: today (July 28th) is the last day
by Hartmut Kaiser 16 Aug '11

16 Aug '11

All, Today is the last day of the review of Tim Blechmann's Lockfree library. If you're interested in this library, please consider contributing a review! If you need more time, please contact me privately. Please see the original (slightly corrected) announcement below: ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::ringbuffer, a wait-free single-producer/single-consumer ringbuffer. The library is accessible from here: http://tim.klingt.org/boost_lockfree.tar.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

6 7