- Boost-users - lists.boost.org

[boost.build] Problems getting PDB files withs DLLs
by Jonathan Jones 19 Sep '12

19 Sep '12

Hi all, I'm having problems getting PDB files built with the DLLs using Boost 1.49 and Visual Studio 2010. I have both debug-symbols=on and debug-store=database specified, but the PDB files are never built. Am I missing something? Thanks, Jon

1 1

(newbie) is_regular_file vs. symlinks in boost::filesystem ?
by Christian Convey 18 Sep '12

18 Sep '12

I'm writing code that takes a file pathname as a command-line argument. My program doesn't care whether the pathname is for a regular file, or if it's a symlink that ultimately leads to a regular file. This seems like such a common usage pattern that I would have expected Boost to have a built-in solution to this problem. But I don't see one. At the moment it looks like I'll have to write code like this: my_path = argv[1]; while (my_path is a symlink) { set my_path to the target of the symlink; error out of a cycle or excessive indirection is detected; } if (! is_regualr_file( my_path )) { tell user there's a problem; } Do I really need to write code like this?

2 3

using boost shared memory
by Dave Dyer 18 Sep '12

18 Sep '12

I'm contemplating using boost to implement inter process communication between a 32 bit process and a 64 bit process. I'm pretty sure there will be no problem at the raw bits level, but I suspect that if I attempt to use any of the higher order constructs, such as allocators or message queues, the disparate size of pointers will make hash of it. Does anyone have any experience (or advice) ?

1 0

Crash in boost::function destructor in my thread pool implementation
by Marcin Adamski 18 Sep '12

18 Sep '12

Hi I am trying to implement thread pool in C++ using pthread and boost::function as a wrapper for any function that client would like to call in the worker thread. I want to encapsulate logic related to threads management in one object which is taking ownership of these threads. That means whenever this object is destroyed, threads must be stopped and cleaned up. I've been testing my code and it turns out that I get segmentation fault when I destroy WorkerThreadManager object while there is boost::function processed in worker thread. See the code in attachment and backtrace from GDB below. I don't really understand why it happens, as far as I know boost::function is copyable, so once I get a copy of it from the queue, I can pop() it and even destroy whole queue (I prooved that in some small test) and then call the function's copy. So why is destruction of std::queue< boost::function<void() > causing problems? Or maybe it is something else. (gdb) bt #0 0xb7ad33a0 in ?? () from /lib/i386-linux-gnu/libc.so.6 #1 0x0807d3a7 in boost::function0<void>::clear (this=0x858db48) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:856 #2 0x0807d17b in boost::function0<void>::~function0 (this=0x858db48, __in_chrg=<optimized out>) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:752 #3 0x0807cec5 in boost::function<void()>::~function(void) (this=0x858db48, __in_chrg=<optimized out>) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:1043 #4 0x0807ced8 in std::_Destroy<boost::function<void ()> >(boost::function<void ()>*) (__pointer=0x858db48) at /usr/include/c++/4.6/bits/stl_construct.h:94 #5 0x0807c868 in std::_Destroy_aux<false>::__destroy<boost::function<void ()>*>(boost::function<void ()>*, boost::function<void ()>*) (__first=0x858db48, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:104 #6 0x0807bd05 in std::_Destroy<boost::function<void ()>*>(boost::function<void ()>*, boost::function<void ()>*) (__first=0x858d938, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:127 #7 0x0807af23 in std::_Destroy<boost::function<void ()>*, boost::function<void ()> >(boost::function<void ()>*, boost::function<void ()>*, std::allocator<boost::function<void ()> >&) (__first=0x858d938, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:153 #8 0x0807a037 in std::deque<boost::function<void ()>, std::allocator<boost::function<void ()> > >::_M_destroy_data_aux(std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>) (this=0x858beec, __first=..., __last=...) at /usr/include/c++/4.6/bits/deque.tcc:795 #9 0x08076153 in std::deque<boost::function<void ()>, std::allocator<boost::function<void ()> > >::_M_destroy_data(std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::allocator<boost::function<void ()> > const&) (this=0x858beec, __first=..., __last=...) at /usr/include/c++/4.6/bits/stl_deque.h:1816 #10 0x08073411 in std::deque<boost::function<void()>, std::allocator<boost::function<void()> > >::~deque(void) (this=0x858beec, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_deque.h:898 #11 0x0806a355 in std::queue<boost::function<void()>, std::deque<boost::function<void()>, std::allocator<boost::function<void()> > > >::~queue(void) (this=0x858beec, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_queue.h:92 #12 0x0815a054 in WorkerThreadManager::~WorkerThreadManager (this=0x858be98, __in_chrg=<optimized out>) at WorkerThreadManager.cpp:42 #13 0x0815a1e3 in WorkerThreadManager::~WorkerThreadManager (this=0x858be98, __in_chrg=<optimized out>) at WorkerThreadManager.cpp:56 #14 0x080c6c51 in std::auto_ptr<WorkerThreadManager>::reset (this=0x85463e4, __p=0x0) at /usr/include/c++/4.6/backward/auto_ptr.h:244 #15 0x080604a9 in main () Regards Marcin Adamski

2 2

[ANN] ODB C++ ORM 2.1.0 released, adds support for Uuid, Multi-Index
by Boris Kolpackov 18 Sep '12

18 Sep '12

Hi, I am pleased to announce the release of ODB 2.1.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. Major new features in this release: * Ability to use accessor/modifier functions and expressions to access data members. In most cases ODB is capable of discovering suitable accessor/modifier functions automatically. * Support for virtual (imaginary) data members that can be used to handle the C++ pimpl idiom as well as aggregate or dis-aggregate real data members. * Ability to define database indexes on data members. Multi-member indexes as well as indexes with database-specific index types, methods, and options are supported. * Support for mapping extended database types, such as geospatial types, user-defined types, collections (arrays, table types, etc.), key-value stores, XML, JSON, etc., to suitable C++ types. * The Boost profile library now provides persistence support for the Uuid and Multi-Index container libraries. * The Qt profile library now provides persistence support for the QUuid type. * Support for generating single (combined) database schema file from multiple C++ header files. This release also adds support for Visual Studio 2012 and Clang 3.1. Specifically, all the runtime libraries, examples, and tests now come with project/solution files for Visual Studio 2012 in addition to 2010 and 2008. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/09/18/odb-2-1-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000018.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12, and Clang 3.1. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

[Review.Coroutine] Coroutine review comments
by Nat Linden 17 Sep '12

17 Sep '12

I like what I see so far, but I'm missing the coroutine future API. We use Giovanni Deretta's Summer of Code Coroutine prototype in production code, and we rely on his 'future' semantics. My intention was to test Oliver's Coroutine proposal by replacing it into our code, but this is not possible without something equivalent to 'future'. Accordingly, this review is based on the library documentation rather than on actual usage. (One could imagine passing a coroutine object itself as a callback for some other library, then calling yield() to await that callback. There are two obstacles. One is that I know of no way to obtain, within the coroutine-function, a reference to the containing coroutine object. The initial 'self' parameter is not that object; it presents a different API. A more serious problem is that the value returned by yield() is fixed by the coroutine template's Signature parameter. With futures, each future object can return a different type; a given coroutine can instantiate an arbitrary number of future objects with an arbitrary number of types to await an arbitrary sequence of callbacks.) > Please always state in your review, whether you think the library should be > accepted as a Boost library! I vote: conditionally accept. I cannot switch to this library without 'future' support. > Additionally please consider giving feedback on the following general > topics: > > - What is your evaluation of the design? Good > - What is your evaluation of the implementation? Did not review > - What is your evaluation of the documentation? Generally good; detailed suggestions follow > - What is your evaluation of the potential usefulness of the library? HIGH. More people need this functionality than realize it. :-) > - Did you try to use the library? With what compiler? Did you have any > problems? I did not > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I read the documentation at the cited link: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ > - Are you knowledgeable about the problem domain? Yes ======================================================================== Detailed comments on documentation: First example in section "Coroutine": "boost::coro::coroutine< void() > c( make_coroutine() );" This example might benefit from a couple comments explaining its purpose. As the first example in the documentation, I thought it might illustrate a short but complete use case. It's only intended to demonstrate a coroutine object being returned by value from a function; but when I first read it I thought make_coroutine() was part of the library API, like make_shared(). "The coroutine-function, as well as its arguments, if any, are copied into the coroutine's state. If a reference is required, use boost::ref." Excellent! This is an important point. "The maximum number of arguments of coroutine-function is 10." Is that limit adjustable with a #define symbol? If not, it should be. Second example under "Executing a coroutine": coro_t c( boost::bind( fn, _1, 7) ); std::cout << "main() starts coroutine c" << std::endl; // yield was called so we returned ^ This comment, at this point in the code, perplexed me. while ( ! ctx.is_complete() ) ^ 'ctx' undefined, I think you mean coro_t 'c' { std::cout << "main() calls coroutine c" << std::endl; // execution control is transfered to c c(); // yield() was called within fn() } "In contrast to threads, which are preemtive, coroutine switches are cooperative (programmer controls when a switch will happen). The kernel is not involved in the coroutine switches." s/preemtive/preemptive/ I would love it if, somewhere in the introductory material, the library documentation emphasized the pragmatic benefit of cooperative switching: it requires no new defensive locking. s/allways/always/ "The arguments passed to coroutine<>::operator()(), in one coroutine, is returned by coroutine<>::self_t::yield() in the other coroutine..." At first glance this makes the reader wonder how yield() can possibly return up to 10 coroutine arguments. May I suggest: "...is returned (as a boost::tuple) by..." ? Example under "coroutine-function with multiple arguments": "boost::tuple< int, int > ret = self.yield( tmp);" This describes exactly the type returned, so is correct. Even so, I find myself thinking that a dubious reader might be more favorably impressed by an example using a couple scalar variables with boost::tie(). And it might clarify the example to use different types for the coroutine parameters. Example under "Exit a coroutine-function": s/self.yield_return()/self.yield_break()/ "An exception thrown inside coroutine-function (transfered via exception-pointer - see Boost.Exception for details and requirements) will be re-thrown by coroutine<>::operator()()." I'm not familiar with Boost.Exception. Will any exception be re-thrown, including exceptions raised by the runtime? Or does this only apply to exceptions derived from a particular base class, or thrown in a particular way? If there are such limitations, mentioning them briefly here would be extremely useful. "Code executed by coroutine must not prevent the propagation of the forced_unwind exception. Absorbing that exception will cause stack unwinding to fail. Thus, any code that catches all exceptions must rethrow the pending exception." This and the example should clarify that we're talking about code within the coroutine-function. (And is forced_unwind also within the boost::coro namespace?) If forced_unwind is the exception thrown when a (! is_complete()) coroutine object is destroyed, that's worth mentioning. It's possible that a coroutine-function might want to perform cleanup specific to that case. coroutine::self_t reference: "T yield( R);" T and R undefined. "template< typename Fn > coroutine( Fn fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() );" flag_unwind_t undefined. "R operator()(A0 a0, ..., A9 a9);" R, A0, ... A9 undefined. Example in section "Generator": Undefined make_generator() function wants a comment. Again, this is a hypothetical user function rather than part of the boost::coro::generator API. "The first argument of generator-function must be of type generator<>::self_t, ..." The "only" argument? I'd like to see some words when generator is first introduced clarifying the ways in which it differs from coroutine. This what I think: * A generator-function accepts no arguments (other than self_t), so yield() always returns void. * yield_break() does not throw an exception in the invoking coroutine. * Anything else? It might be worth a few words to clarify that when you pass a boost::bind() expression, *that* is the generator-function, and it must accept only self_t. Any other parameters bound by boost::bind() are irrelevant to boost::coro::generator. In that connection, the function f() in the first "Executing a generator" example should probably accept a different parameter type than int so the reader can clearly distinguish between the type accepted by f() and the type passed to yield(). And in *that* connection, the self.yield() call in that example should pass an int value. "The generator-function, as well as its arguments, if any, are copied into the generator's state." Um, what arguments? Again, if you're using boost::bind() to adapt a function that accepts anything more than self_t, processing of additional arguments is up to boost::bind() -- not boost::coro::generator. "The maximum number of arguments of generator-function is 10." What does this mean? "generator-function is invoked the first time inside the constructor of generator." That makes no sense to me. Is the value passed to the first yield() call simply discarded? If so, why? "If generator-function can not return valid values anymore generator<>::self_t::yield_break() should be called. This function returns the execution control back to the caller and sets the generator to be complete (is_complete() returns true)." is_complete() is not documented for boost::coro::generator. "Of curse the generator-function can be exited with a return expression." s/curse/course/ Is there any semantic difference between executing 'return' in a generator-function and calling yield_break() in a generator-function? If not, is yield_break() provided only for consistency with coroutine? If a generator-function has a declared return type, is that value discarded? Example in "Exit a generator-function": "self_yield( i);" should be self.yield(i); "self.yield_return();" should be self.yield_break(); class generator::self_t reference: "void yield( R);" Is R the same as Result here? "Result operator()() Preconditions: *this is not a not-a-generator, ! is_complete()." is_complete() is not documented for boost::coro::generator. "void self_t::yield( Result) Effects: Gives execution control back to calling context by returning a value of type Result. The return type of this function is a boost::tuple<> containing the arguments passed to generator<>::operator()()." That entire last sentence seems untrue. "void self_t::yield_break() Effects: Gives execution control back to calling context and sets the generator to be complete. generator<>::operator()() in the other generator throws exception coroutine_terminated." Last sentence above contradicts other generator documentation.

2 7

If *boost::filesystem::path::iterator was mutable it would be considerably more user friendly
by Sebastian Karlsson 17 Sep '12

17 Sep '12

Why is *boost::filesystem::path::iterator immutable? If it wasn't transformation of paths would be very user friendly, and we'd be able to leverage all the niceties which already works with iterators. As it is one has to create a ton of temporaries, and common operations which should be one liners becomes a mess. Kind regards, Sebastian Karlsson

1 0

[Review:Contract] Boost.Contract Library is Accepted
by Dave Abrahams 17 Sep '12

17 Sep '12

Lorenzo Caminiti's Boost.Contract Library is hereby accepted into Boost. I will be brief but that should in no way be construed as a lack of enthusiasm. Reviewing the review commentary was a genuine pleasure. Anyone interested in this domain could learn a lot by going through the threads the way I did. There were five "yes" votes, one of which was very late (but I'm counting it), and one of which was conditional, and one "no" vote. I am accepting the library unconditionally because of Lorenzo's demonstrated responsiveness to issues. He gave thoughtful responses to the review comments and entered every issue raised that remained open into a bug database (http://sourceforge.net/apps/trac/contractpp/report/3) Congratulations, Lorenzo! -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[boost] [contract] static_assert in contracts or not?
by Lorenzo Caminiti 17 Sep '12

17 Sep '12

Hello all, If static assertions make sense within contracts (preconditions, postconditions, and class invariants) is a questions that has been raised by both Vicente and Andrzej. I don't have a definitive answer so I'd like to discuss with the ML. On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > (6) > Static assertions: is there any value in providing them, given that we > already have this ability in Boost? I see that N1962 decided to abandon > them; I am pretty sure the reason was that static_assert was already there. > They somehow do not fit conceptually into the model of preconditions, > postconditions and invariants. Precondition, for instance tries to detect a > run-time condition occurring immediately before a function is called this > time. Static assertion is not even executed then. What point is there in > putting such assertion into the precondition? Documentation says " static > assertions can be selectively disabled depending on where they are > specified [...] so it is still important to logically associate them with > preconditions, postconditions, etc." -- technically this sentence makes > logical sense, but can you think of a single example where this selective > disabling of assertions would be useful? What is the point in disabling > such assertions at all, if they cost you nothing in run-time? I propose to > remove them and give a sort of recommendation that software quality is > assured by using a number of fairly independent tools: DbC, concepts, > static assertions. I think we can break down the question in two parts. Let's assume N1962 is accepted into C++1x so we have both contracts and static_assert. 1) Would you expect to be able to use static_assert within contract assertions (preconditions, postconditions, and class invariants)? Note that only boolean conditions are allowed by N1962 within contracts, general code is not allowed, therefore this is not a trivial question. For example, would you expect to be able to do the following option A: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } In this case, would it ever make sense to use static_assert in postcondition and/or class invariants even if that were allowed? Or would you just use static_assert in the body, option B: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); // ... } I don't like this because the assertions are about the specifications (they assert a requirement of the interface) so they should go in the declaration and not in the implementation. Or maybe the assertions should be represented as concept requirements on To and From, option C: template< typename To, typename From > requires SizeofGreaterEqual<To, From>, Convertible<From, To> To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { // ... } (Only we don't have concepts...) 2) Let's assume, we answered option A to question 1): template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } Would you expect these static_asserts to be disabled when precondition compilation and checking is turned off at compilation time? I'd think so. Thanks. --Lorenzo

3 2

Using Boost.Process on Windows
by Ronan Trépos 15 Sep '12

15 Sep '12

Hello, I'm trying to compile start_child example of Boost.Process with this configuration: Windows 64 bits MinGW g++ 4.6.2 boost_1-51 Boost.Process 0.5 And I have this error: error: no matching function for call to 'boost::system::system_error::system_error(DWORD, const boost::system::error_category& (&)(), const char [54])' note: candidates are: boost::system::system_error::system_error(int, const boost::system::error_category&, const char*) ... This difficulty was mentioned on the list "[Boost-users] [Process] Can't build example" at date 12/4/10. Am i missing something ? Thank you in advance Best regard Ronan Trépos -- Trépos Ronan INRA unité BIA, équipe MAD, Toulouse http://carlit.toulouse.inra.fr/wikiz/index.php/Ronan_TREPOS tel : 05 61 28 51 89

3 3