- Boost - lists.boost.org

The need for a 1.35.1 release
by James Talbut 15 Jun '08

15 Jun '08

As a user I am concerned about the lack of a 1.35.1 release. We cannot use 1.35 because it contains a bug. When 1.36 is released it will fix this bug, but it will also inevitably introduce new bugs some of which may also be show-stoppers for us. Which means we have to wait for 1.37, and so on... We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library). Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

5 5

[serialization] [1.35.0] Potential Memory Buster, Deserializing std::vector<T, boost::pool_allocator<T> >
by Dean Michael Berris 15 Jun '08

15 Jun '08

Hi Everyone, In the 1.35.0 release, I see that boost/archive/array/iarchive.hpp has a commented out 'load_optimized' function which is not commented out in the trunk. When deserializing to an std::vector<uint32_t, boost::pool_allocator<uint32_t> >, I see that the optimized implementation will first get the correct size, set the receiving container's size correctly, and then put the contents of the array into the container. The question I have is why is this function commented out in the 1.35.0 release? I had to find out the hard way that this causes insane memory usage when deserializing to an std::vector<uint32_t, boost::pool_allocator<uint32_t> >, mainly because if it uses an implementation that grows the vector one element at a time, can (and usually would) cause multiple calls to resize the container and make a lot of calls to the pool allocator. The way the pool allocator grows causes an abrupt usage in memory unnecessarily. Should this be considered a blocker issue that merits a 1.35.1 release? Insights would be most appreciated. My solution for the meantime is to stick to the Boost svn trunk version that I know the current application I'm working on works fine with -- eventually though I hope to be able to move to a "stable" Boost release. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

3 6

[filesystem] path normalization
by Emil Dotchevski 14 Jun '08

14 Jun '08

Shouldn't path normalization remove trailing "/."? In other words, shouldn't "foo/bar/." normalize to "foo/bar"? Similarly for leading "./", don't we want "./foo/bar" normalize to "foo/bar"? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[thread-pool/futures] Explicit yielding
by Johan Torp 14 Jun '08

14 Jun '08

There has been some discussions about exposing a wait-callback in futures, a hook which is executed whenever someone calls wait. One of the motivations has been to efficiently re-use threads within a thread pool when a task is waiting on a future. The idea is to execute another task in the future::wait() call to avoid thread context switching and to need less worker threads. I've presented some arguments why this might cause unexpected problems. Here is a very crude draft of an alternative thread-pool interface which would allow thread re-use but in an explicit way. Let launch_in_pool come in two flavours, one without surprising thread re-use and one with explicit support for it. I hope the interfaces are self-explanatory. template<class R> future<R> launch_in_pool(function<R()> task); template<class R> future<R> launch_in_pool(function<R(thread_pool& pool)> task); /// The thread_pool class is only to be used by code executed by worker threads class thread_pool { template<class R, class F> future<R> submit_child_task(const F& child_task); enum yield_type {YIELD_TO_CHILD_TASK, YIELD_TO_RELATED_TASKS, YIELD_TO_ANY_TASK}; /// Waits until all child tasks are ready void yielding_wait(yield_type yt); }; Thoughts? Johan -- View this message in context: http://www.nabble.com/-thread-pool-futures--Explicit-yielding-tp17606225p17… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 16

Constructor with parameters -- Lambda
by albert meyburgh 13 Jun '08

13 Jun '08

Hi, I'm trying to use the lambda constructor provided in boost and it's not compiling. class someclass { someclass(sometype, int x) } std::vector v<sometype> std::vector v2<someclass> std::transform( v.begin(), v.end(), std::back_inserter( v2 ), boost::bind( boost::lambda::constructor<someclass>(), _1, 5) ); // where 5 is a constant int parameter for x to the constructor Resulting in Error 1 error C2039: 'result_type' : is not a member of 'boost::lambda::constructor<T>' boost_1_35_0\boost\bind.hpp 67 Error 2 error C2146: syntax error : missing ';' before identifier 'type' boost_1_35_0\boost\bind.hpp 67 Error 3 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boost_1_35_0\boost\bind.hpp 67 Error 4 error C2208: 'boost::_bi::type' : no members defined using this type boost_1_35_0\boost\bind.hpp 67 Error 5 fatal error C1903: unable to recover from previous error(s); stopping compilation boost_1_35_0\boost\bind.hpp 67 What is wrong with my syntax?

3 2

[ANN] xpressive v2.1
by Eric Niebler 13 Jun '08

13 Jun '08

I've uploaded to the Boost Vault a new version of xpressive. This should be the version that ultimately becomes part of Boost 1.36. If anybody find problems, pls. let me know. New Features: * skip(), for specifying which parts of the input sequence to ignore when matching it against a regex. http://tinyurl.com/5xndnk (<http://boost-sandbox.sourceforge.net/libs/xpressive/doc/html/boost/xpressiv…>) * regex_replace() accepts formatter objects and formatter expressions, in addition to format strings. http://tinyurl.com/4c8rt4 (<http://boost-sandbox.sourceforge.net/libs/xpressive/doc/html/boost_xpressiv…>) * Range-based regex_replace() algorithm. http://tinyurl.com/4awtoh (<http://boost-sandbox.sourceforge.net/libs/xpressive/doc/html/boost/xpressiv…>) Bugs Fixed: * Crash when semantic actions are placed in look-aheads, look-behinds or independent sub-expressions. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

CORBA iimplementation for Boost interest?
by Jonathan Biggar 13 Jun '08

13 Jun '08

I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill. Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services. I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed. So, what do you all think? -- Jon Biggar Floorboard Software jon(a)floorboard.com jon(a)biggar.org

11 55

[serialization] Boost 1.35.0 version breaks backward compatibility.
by Jurko Gospodnetić 12 Jun '08

12 Jun '08

Hi all. I am not sure if this was the desired or even acceptable effect but Boost 1.35.0 version of the serialization library introduces an optimization in vector.hpp when serializing a std::vector of 'trivially constructible' types (e.g. int :-)) that breaks backward compatibility when serializing into a text archive. Example for a std::vector<int> holding values { 2, 4 }: Old implementation: '2 0 2 4' New implementation: '2 2 4' We found a workaround to make boost use the old serialization implementation by wrapping our 'default constructible' objects inside a a simple class with a non trivial constructor. None of this is documented in http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/release.html#di…. ----------------------- Some related questions: ----------------------- * Does anyone know if Boost serialization library is intended to remain backward compatible across different Boost releases or at least provide for explicitly turning on such backward compatibility? * What to do when one wants to use new & improved serialization algorithms but needs to occasionally support older ones in the same application? I know our class serialization can be conditioned based on some 'version' parameter but what to do about 'standard' classes, e.g. std::vector<int>, whose serialization is implemented by the Boost serialization library itself? For example, a new 'network application' release supports a new & improved serialization algorithm but still wants to support connecting to old 'network applications' that do not know how to 'speak the new language'. Many thanks for any explanation regarding this topic. On a related but separate issue - The optimization is conditioned on whether the type is 'default constructible' which seems incorrect. Default constructibility test as currently implemented does actually just test whether the constructor is trivial (using a compiler specific intrinsic) but that is not what the name 'has_default_constructor()' suggests. Hope this helps. Best regards, Jurko Gospodnetić

2 1

[thread] condvar wait exception
by Emil Dotchevski 12 Jun '08

12 Jun '08

Hello, I'm reading in the documentation that barrier::wait may throw thread_resource_error. Looking at the source, it uses condition_variable::wait, which in turn (I think) throws nothing on windows, but may throw boost::condition_error under pthread. So the documentation appears to be wrong. But also, I am puzzled why would wait() throw anything but boost::thread_interrupted? Let's say I have two threads call wait() on a barrier, and one of them throws an error. What am I supposed to do with that exception? How can I recover from such a failure? I am not an expert but I think that if the exception is used to report a bug in user code, it would be better to assert() instead of throwing an exception. One final note, Boost Thread doesn't use boost::throw_exception to throw exceptions. This means that the exception_ptr functionality in Boost Exception is crippled for exceptions emitted by Boost Thread. This is unfortunate because transporting exception objects between threads is a key motivation for boost::exception_ptr; see http://svn.boost.org/svn/boost/trunk/libs/exception/doc/cloning.html. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

erfc id not found
by Gary.Stevens＠deq.idaho.gov 12 Jun '08

12 Jun '08

I have been trying to compile code that uses the erfc function. I can get it to build successfully using DevC++4.9.9.2, but cannot using Win-Visual C++2005 Express (C90 standard) which I have been using to construct a form for input-output. I have downloaded the boost libraries and have changed the configuration properties to include the boost directory and changed to Not Using Precompiled Headers. I continue to receive the following: 'erfc': identifier not found. I have tried adding the libraies for DevC++4.9.9.2 but receive the same error. I am new to C++ and this a small simple program but am spending a significant amount of time getting the erfc issue resolved. Any help would be very appreciated. Thank you. Gary

2 4