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

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[multi_array] Ticket#4874 "multi_array compile errors using Visual C++ 2010 in debug mode"
by Stephan T. Lavavej 02 Nov '11

02 Nov '11

Hi Boost devs, VC10 users are occasionally encountering https://svn.boost.org/trac/boost/ticket/4874 and reporting it to MS. For example, see http://connect.microsoft.com/VisualStudio/feedback/details/687655/compilati… where I've explained what's going on (I wrote this analysis back in Feb 2010 and I believe it's still correct): The problem is that multi_array iterators report themselves as input iterators, which can't be written to (e.g. as the destination of a copy()). Under IDL=0, copy() doesn't actually care how its destination iterator is marked with an iterator category tag, it just tries to write to the destination iterator, and that works. Under IDL > 0, copy() wants to know whether its source and destination iterators are both random-access, in which case it can perform a range check and unwrap the destination iterator for increased performance. It does this by overloading foo(input_iterator_tag, output_iterator_tag) and foo(random_access_iterator_tag, random_access_iterator_tag) and calling foo(category(source), category(destination)). If both source and destination are random-access, both overloads are viable (i.e. callable) and the second overload is preferred, so it's actually called. Otherwise, source is required to be at least an input iterator (maybe stronger) and destination is required to be at least an output iterator (maybe stronger) so the first overload must be viable and the second overload will be non-viable, so the first overload wins by default. However, if the destination is not marked as an output iterator or stronger, then the first overload is non-viable as well as the second, so overload resolution fails and boom. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer

2 1

[signals2] 'static initialisation fiasco' issues
by elpidio valdez 25 Oct '11

25 Oct '11

I am trying to build a modular system in which independently compilable cpp files communicate by signals, but otherwise know nothing about each other at compile time. e.g. #include "TheRangeFinderSignals.h" #include "TheProximitySensorSignals.h" class TerrainMap { ....connect to signals and send signals.... } TheSingletonTerrainMap; This all works very well except that TerrainMap needs to connect to signals from its constructor. The signals are static global objects which serve to exchange data between the independent modules. Unfortunately I have fallen foul of C++ static initialisation problems. I cannot be certain that the static signal objects will be created before the modules that use them. The C++ FAQ recommends wrapping the static variables in a function: e.g. EventSignal<void (Gray16Image)> &OnNewDepthFrameAvailable() { static EventSignal<void (Gray16Image)> *zzz = new EventSignal<void(Gray16Image)>; return *zzz; } This works but it is syntactically messy to use. All uses of OnNewDepthFrameAvailable must be replaced with OnNewDepthFrameAvailable(). i.e OnNewDepthFrameAvailable().connect(...) OnNewDepthFrameAvailable()(theNewFrame); Is there any way to avoid this ? It is not easy to hide the detail. I wanted to define a template class to encapsulate the idiom and eliminate the need for the extra parenthesis. e.g. SafeStatic< EventSignal<void (Gray16Image)> > OnNewDepthFrameAvailable; template<type T> class SafeStatic { T *obj; void operator()(theArgsToSignal) { if (!obj) obj = new T; obj(theArgsToSignal); } }; The problem is that the Signal template defines a variable arity and signature operator(). I have no idea how to provide the same signature on the function call operator of SafeStatic Any other way around this problem ?

2 1

Status of boost::make_shared_array
by Olaf van der Spek 24 Oct '11

24 Oct '11

Hi, What's the status of boost::make_shared_array? I've seen some discussion from 2009, but it's almost 2012 now and it doesn't appear to be available. Greetings, Olaf

2 11

Unittest capability for meta-programs feedback request
by Ben Robinson 16 Oct '11

16 Oct '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. The submission source is available at https://github.com/icaretaker/Metatest. The provided examples are based on the factorial metafunction from Chapter 8 of "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy - http://www.boostpro.com/mplbook/. Chapter 8 explains the rational behind the BOOST_MPL_ASSERT_* macros. This submission complements these macros by allowing the writing of regression unit tests, to ensure the user will encounter the mpl formatted compiler error, if the library types are incorrectly instantiated. Currently, many meta-programs are written using one of the BOOST_MPL_ASSERT_* macros. Unit tests for these metaprograms must of course compile, therefore unittests for these programs can verify that valid types produce the correct run-time behavior. This submission provides the following four complementary macros: BOOST_METATEST(pred) BOOST_METATEST_NOT(pred) BOOST_METATEST_RELATION(x, rel, y) BOOST_METATEST_MSG(cond, msg, types) Meta-program authors can use these macros to assert predicates/relations/conditions exactly as done with BOOST_MPL_ASSERT_*. In shipped library code, these four macros exactly forward to their BOOST_MPL_ASSERT_* counterparts, since the BOOST_MPL_ASSERT_* macros do an excellent job of providing maximally informative compiler error messages. In unit test code (where BOOST_METATEST_RUNTIME will need to be defined), these macros will instead instantiate an object, which will throw a runtime exception if the predicate/relation/condition fails. Now meta-program authors can write unittests like the following: BOOST_AUTO_TEST_CASE(factorials_should_not_be_negative) { BOOST_CHECK_THROW( factorial<mpl::int_<-1> > instance;, metatest_exception ); } As you can see, this unit test validates that the factorial meta-function will in fact fail to compile. All exceptions are subclassed from boost::metatest_exception. If the user would instead like to supply their own exception types for individual assertions, one of the following four macros can be used alternatively: BOOST_METATEST_EXP(pred, exp) BOOST_METATEST_NOT_EXP(pred, exp) BOOST_METATEST_RELATION_EXP(x, rel, y, exp) BOOST_METATEST_MSG_EXP(cond, msg, types, exp) Another feature of this library, is that it is independent of any unit testing framework, provided the framework can catch exceptions by type. The examples provided show how this is done with Boost Test. The submission files also show how to use try/catch directly should your unit test framework not have such a capability. I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

16 40

Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 14 Oct '11

14 Oct '11

Hi all! Not so long ago I was looking for a solution to Base64 encoding/decoding. In this page - http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/dataflow.html - I found example of such solution, with 'base64_from_binary' and 'transform_width' iteartors. But it is just a "blank", not ready-to-use solution. I created solution. But I definitely know many developers looking for a simple, ready-to-use, header-only and 'real C++' solution for Base64. So I want to offer you such solution. Some examples: int main() { std::string my_text = "My text for encoding!"; std::string encoded_text = boost::base64().encode( my_text ); std::string my_text_again = boost::base64().decode< std::string >( encoded ); } For binary data: int main() { typedef std::vector< unsigned char > binary_string; binary_string my_bin = list_of( 0xFF )( 0xAA )( 0x01 ); std::string encoded_bin = boost::base64().encode( my_bin ); binary_string my_bin_again = boost::base64().decode< binary_string >( encoded ); } For streams: int main() { boost::filesystem::ifstream my_jpeg( "/some/path/to/my/image" ); // fstream checking omitted... std::string encoded_jpeg = boost::base64().encode( my_jpeg ); boost::filesystem::ofstream my_jpeg_again( "/some/path/to/decoded/image" ); // fstream checking omitted... boost::base64().decode( encoded_jpeg, my_jpeg_again ); } This is first variant. IMHO such solution will be useful for Boost users. What you think about it? - Denis

7 27

Checking interest in to_string functions
by Antony Polukhin 13 Oct '11

13 Oct '11

As was mentioned in `[boost] to_string(v)` 1) Functions to_string and to_wstring are part of the upcoming C++0x standard. However, there are no functions for char16_t and char32_t conversions. 2) Some users can't use C++11 in some projects for quite some time, but can use boost. 3) "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Some users would like to use a shorter form. Is there interest in stoi, stoll, stof, to_string, to_wstring, to_u16string, stod and other functions for char, wchar_t, char16_t and char32_t conversions? Shall I add them to lexical_cast library, or as a separate conversion library? Best regards, Antony Polukhin

8 15

[Review] Review results for Lockfree
by Hartmut Kaiser 07 Oct '11

07 Oct '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

5 8

[property_tree] include directive for non-info files
by Ivan Le Lann 07 Oct '11

07 Oct '11

Hi, In Boost.PropertyTree, INFO format has the nice #include directive. But it seems you cannot include other formats. Typically such INFO file, key { #include_xml "my.xml" } with "my.xml" : <root><child>kid</child></root> could give : get<std::string> ("key.root.child") == "kid" A very quick look at info parser makes me think that it would be easy to implement. Any comment ? Regards, Ivan

2 1

Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
by Andrew Hundt 06 Oct '11

06 Oct '11

I've implemented a small companion class to boost.array that functions like a stack allocated vector with fixed capacity. The motivation for this class came when I was using boost.array in an interprocess library, when I realized that I actually desired an adjustable size boost.array, without the complexity of the vector class in the interprocess library. The result is StaticVector, which is boost.array directly modified with a size in front of the array, and added facilities to match std::vector. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Sample Code: StaticVector<std::size_t,3> three; three.push_back(5); three.push_back(2); // size: 2 capacity: 3 three.push_back(3); three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded So here is the big question: Is there any interest in the class? Cheers! Andrew Hundt

7 12