January 2013 - Boost - lists.preview.boost.org

[Serialization] Bizarre bug - reviewed
by Tobias Loew 17 Jan '13

17 Jan '13

I just came across the following bug http://boost.2283326.n4.nabble.com/Serialization-Bizarre-bug-td2612558.html and noticed that the bizarre behaviour is still reproducible (I used boost-version 1.52). I could figure out that in the buggy build there is an additional static initialization of the singlenton<T>::instance in boost\serialization\singleton.hpp in line 149 at startup > serial_bug.exe!`dynamic initializer for 'boost::serialization::singleton<boost::archive::detail::pointer_oserializer<boost::archive::text_oarchive,std::vector<char,std::allocator<char> > > >::instance''() Zeile 149 C++ which leads to a call of set_bpis in iserializer.hpp line 347. Thus, std::vector<char> will be saved (but NOT loaded) through a pointer. For apps that store and load the same types the problem usually does not arise, but for server/clients this may not be the case (e.g. apps using the RCF-library) Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-Bizarre-bug-reviewed-tp464… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Changes to VS 2012 config
by Marshall Clow 17 Jan '13

17 Jan '13

Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012. The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features. If you see any problems, please let me know. -- Marshall

14 26

Interest in breakable labeled scope emulation?
by TONGARI 16 Jan '13

16 Jan '13

Hi all, One of the few things I appreciate in Java is the labeled-break feature. I think C++ would provide it as well in future standard but it seems that there's no even such a proposal. In lack of the language feature, a simple emulation can be used: --------------------------------------------------- #define BOOST_SCOPE(name) \ if (const bool LABELED_SCOPE_##name = false){break(name); name:;} else #define break(name) \ (void)LABELED_SCOPE_##name; goto name; --------------------------------------------------- Now we can write: BOOST_SCOPE(a) { break(a); cout << "123\n"; } The real world usage would reside in nested loop&switch where labeled-break really shines. Thoughts? Sorry if this idea is too simple and somewhat rejected before...

7 22

[thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
by Vicente J. Botet Escriba 14 Jan '13

14 Jan '13

Hi, in order to fix this issue, https://svn.boost.org/trac/boost/ticket/5752 : "boost::call_once() is unreliable on some platforms", I would like to use Boost.Atomic as suggested on the ticket. As Boost.Atomic is not a header-only library the user would need to link with boost_atomic. Is this an acceptable change? I'm requesting this as recently there were some people reactive to some changes in Boost.Thread. Would this be considered an compatibility issue? If yes should the fix for the call_once issue be included if the user request it using conditional compilation or even go on a separated version of Boost.Thread? Thanks, Vicente

6 44

[serialization] round-trip serialization of float
by Adam Lerer 14 Jan '13

14 Jan '13

The boost serialization of float doesn't appear to use enough digits to guarantee that deserialization of a serialized value will produce the same value. The relevant code is in boost/archive/basic_text_oprimitive.hpp: void save(const float t) { os << std::setprecision(std::numeric_limits<float>::digits10 + 2); ... } std::numeric_limits<float>::digits10+2=8, but float actually requires numeric_limits<float>::max_digits10=9 decimal digits to guarantee unique representation. The code below (with boost/1.52) demonstrates the problem: #include <sstream> #include "boost/archive/text_iarchive.hpp" #include "boost/archive/text_oarchive.hpp" #include <iostream> int main(int argc, char **argv){ float oldf = -1.20786635e-05; std::ostringstream os; boost::archive::text_oarchive oa(os); oa & BOOST_SERIALIZATION_NVP(oldf); float newf; std::istringstream is(os.str()); boost::archive::text_iarchive ia(is); ia & BOOST_SERIALIZATION_NVP(newf); printf("before serialization: %.12g\nafter serialization: %.12g\n", oldf, newf); } // Output: // before serialization: -1.20786635307e-05 // after serialization: -1.20786644402e-05 Note: There's some discussion of this topic in a slightly different context here: http://boost.2283326.n4.nabble.com/serialization-Serialisation-deserialisat…

5 8

[thread] thread::join() + thread::interrupt() not reliable?
by Oliver Kowalke 14 Jan '13

14 Jan '13

Hi, following code does not work reliable - sometimes the output is thread_interrupted thrown by t1 in main(): false thread_interrupted thrown by t1 in fn2(): false done and sometimes I get an exception terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >' what(): boost thread: thread not joinable: Invalid argument I would expect that thread_interrupted will be catched in main() and fn2() as the documentation describes. Oliver #include <iostream> #include <boost/assert.hpp> #include <boost/bind.hpp> #include <boost/thread.hpp> void fn1( boost::barrier * b) { b->wait(); boost::this_thread::interruption_point(); } void fn2( boost::thread * t1, boost::barrier * b, bool * interrupted) { t1->interrupt(); b->wait(); try { t1->join(); } catch ( boost::thread_interrupted const&) { * interrupted = true; } } int main() { bool interrupted1 = false, interrupted2 = false; boost::barrier b( 2); boost::thread t1( boost::bind( fn1, & b) ); boost::thread t2( boost::bind( fn2, & t1, & b, & interrupted2) ); try { t1.join(); } catch ( boost::thread_interrupted const&) { interrupted1 = true; } t2.join(); std::cout << "thread_interrupted thrown by t1 in main(): " << std::boolalpha << interrupted1 << "\n"; std::cout << "thread_interrupted thrown by t1 in fn2(): " << std::boolalpha << interrupted2 << "\n"; std::cout << "done\n"; }

2 3

[1.53.0] Beta1 release available
by Marshall Clow 14 Jan '13

14 Jan '13

Boost release 1.53.0 beta 1 is now available from SourceForge. See https://sourceforge.net/projects/boost/files/boost/1.53.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_53_0.html. Please download the beta, give it a try, and report any problems you encounter. Thank you, -- The Boost Release Team Beman Dawes, Eric Niebler, Rene Rivera, Daniel James, Vladimir Prus and Marshall Clow.

3 4

Boost.iostreams on Android - Fails on multichar input filters
by Sukender 14 Jan '13

14 Jan '13

Hi, I found iostreams "filtering_stream_test" to fail under Android (32 bits, gcc 4.6, boost 1.52.0) : " Running 18 test cases... read_input_filter_test.hpp(88): error in "read_input_filter_test": failed reading from a filtering_istream in chars with a multichar input filter read_input_filter_test.hpp(101): error in "read_input_filter_test": failed reading from a filtering_istream in chunks with a multichar input filter " Note : I ran some tests by compiling on the host machine (64-bits Linux), then manually copying/running on the (emulator) device (using "adb push" / "adb shell"). I know Android is not actively maintained, but I need multichar filters (gzip_compressor & gzip_decompressor are multichar and thus fail). And I wonder why this test fails. I could not run the regression test on iOS, but my original code (using gzip_decompressor) works as expected under iOS, and Windows, and MacOSX. I have no clue about how to solve the issue. Any idea? Thank you. Cheers, Sukender

1 1

(no subject)
by schouwla＠yahoo.com 13 Jan '13

13 Jan '13

http://thefadersdjs.com/assistbunchshaunturner/

1 0

Re: [boost] Flow-based programming library for Boost?
by Marcus Tomlinson 13 Jan '13

13 Jan '13

>> * You use a bus of input/output untyped signals. Why the signals are not >> typed? 1. Flexibility - inputs and outputs can dynamically accept changing signal types. E.g. Varying sample size in an audio stream. 2. Less coding, more expandability - the component designer need not specify the types required at each input / output when configuring IO, only how many. Consider the situation where you would like to update a component to accept int instead of bool for one of its inputs. This would (in your implementation) require you to edit multiple sections of code. With DSPatch, you need only edit / add to the process method. 3. Allow for generic virtual base process method (explained below). >> * Why do you need that the process function be virtual? This is due to the way the circuit works in DSPatch. When a component is required to process, the circuit needs a way of triggering it without having to know anything about the specifics (input / output count, types etc.) of that particular component. A generic inherited virtual method guarantees this kind of catch-all interface. >> // 1. Derive component class from DspComponent >> // =========================================== >> class DspAnd : public DspComponent<DspAnd, InPort<bool>,InPort<bool>, >> OutPort<bool>> >> { >> typedef DspComponent<DspAnd, InPort<bool>,InPort<bool>, OutPort<bool>> >> base_type; >> public: >> // 2. Configure component IO buses >> // =============================== >> DspAnd(DspComponentBase& parent, Signal<bool>& x, Signal<bool>& y, >> Signal<bool>& o) >> : base_type(parent, x, y, o) >> { >> } These requirements for component construction are quite overwhelming. There is a lot to remember (and type) every time you need to create / edit a component. Besides, as mentioned before, flexibility is paramount with DSPatch. This kind of static IO configuration goes against DSPatch's design (more on this later). >> protected: >> // 3. Implement a non-virtual operator() method >> // ====================================== >> bool operator()(bool x, bool y) >> { >> return x && y; >> } >> }; Having to keep track of every component input and output (count, types, etc) in multiple places (constructor, operator(), and in external use) seems overly complex and difficult to expand on / maintain. And again, static IO configuration is quite limiting. >> void main() >> { >> // 1. Create a DspCircuit where we can route our components >> // ======================================================== >> DspCircuit circuit; >> // 2. Create the internal signals >> DspSignal<bool> i1, i2, o; >> // ======================================================== >> // 3. Create instances of the components needed for our circuit and >> connect the signals and the ports >> // ============================================================ >> DspRandBool randBoolGen1(circuit, i1); >> DspRandBool randBoolGen2(circuit, i2); >> DspAnd logicAnd(circuit, i1,i2,o); >> DspPrintBool boolPrinter(circuit, o); Firstly, I like how the signals are referenced externally and are common between all components. This is something I need to improve on in the circuit class. ATM there is a fair amount of data copying going on. I assume that in your idea of this type of implementation, there is still a means of disconnecting and reconnecting signals at a later point? Wiring and rewiring at runtime is a large emphasis of the DSPatch design. I'm not sure wiring at construction is all that important though -I especially don't think it should be mandatory. This looks like the kind of code you'd find in other dataflow libraries. However, this is exactly why I designed DSPatch, and why I designed it the way I did. In my opinion, the code is convoluted (doesn't read well). But alas, I fear that most people actually prefer this kind of syntax over mine. >> Components with several outputs should define a operator() returning the >> tuple of outputs. Much like your implementation of input configuration, tuples have to be defined at compile time and hence can't be adjusted at a later point. By design, DSPatch avoids static IO, in fact it tries to avoid anything that is static. Not only does DSPatch allow you to adjust IO types and runtime, you can add / remove IO dynamically too. E.g. An AI minimax tree where each node dynamically creates a new output, and a feedback input for each possible player move from current position. It may be worth mentioning (again) that DSPatch was originally designed for audio DSP applications (hence the name). Therefore runtime features like branch synchronization, dynamic routing, and adaptive IO signal types are all part of the core design requirements. These features then subsequently cover a very large range of applications, allowing for small, simple static circuits, to large, complex dynamic circuits. I hope this helps you understand why DSPatch is designed the way it is.

3 8

[1.53] [multiprecision] Still time for bug fixes?
by John Maddock 12 Jan '13

12 Jan '13

If there's still time (and the test results need to cycle first), I'd like to merge this bug fix: https://svn.boost.org/trac/boost/changeset/82460 for this bug: https://svn.boost.org/trac/boost/ticket/7878 Which causes integer division to fail in some cases. Thanks, John.

3 2

Re: [boost] [non-instrusive move] interest in new library?
by THOMAS JORDAN 11 Jan '13

11 Jan '13

Thomas Jordan wrote: >Jeffrey Lee Hellrung, Jr. wrote >> You didn't really expound on the implementation, but, if I had to guess, >> you'd also require your types to be default constructible, and it would >> perform suboptimally (worse than leaving the move call out) if the swap >> member function was equivalent to std::swap. I think this might preclude >> its use in generic contexts and limit its use to situations where you >> *know* the type is std::vector-like. Let me know if I'm presuming >> incorrectly :) >> > >Yes, it certainly requires the types to be default constructible. > ><snip> > >The alternative would be to have just the single, default, template move >function: > >//pseudo-code >move(T& left, T& right) > >plus a pair of template functions to move to and from temporaries >respectively: > >T move(T& x) >void move(const T& from, T& to) > >then have optimised move functions defined on a per-type basis, e.g., > >MyClass >{ > void swap(MyClass& other) > { > //efficient swap member > } > > friend void swap(MyClass& lhs, MyClass& rhs){} > > friend void move(MyClass& lhs, MyClass& rhs) > { > lhs.swap(rhs); > } >} > >as well as overloads defined for any cheap-to-swap library types >interested in: > >void move(std::vector& lhs, std::vector& rhs){} >void move(boost::function& lhs, boost::function& rhs){} >etc. > >Although this is safer in that it should ensure optimality - and is >actually where I started - it requires more boilerplate to be written, >though there may be way(s) to automate the generation of the the >user-type's move function. Also, with the library move functions >implemented like this, you could still write algorithms like >move()/move_backwards() (and helper functions >such as iter_move() to move the values between two iterators) generically. Also generic overloads of the move() function would be provided for built in arrays and e.g., boost::array //pseudocode void move(boost::array<T,N>& from, boost::array<T,N>& to){} void move(T (& left)[N], T (& right)[N]){} which would be implemented with a call to move(left[i], right[i]) for each element, in which case the elements would be swapped if a move overload has been defined for the element type, copied otherwise, thereby preserving optimality. It would work for multi-dimensional (boost) arrays in a recursive fashion. >So I guess the new question is, would this even smaller library be of >any interest? >Its use-cases would be the same as described in my original post, just >to reiterate: > >//use-case: returning a argument directly from a function > >std::string foo(std::string s) >{ > //e.g., append something to s > //... > > //compiler can perform rvo (compiler would likely not > //perform nrvo if just used 'return s;') > > return move(s); >} > > >//use-case: moving a value to a function/ctor, when the value is not >//required by the calling code after the function/ctor call > >std::string s("hello"); >void bar(std::string s){...} > >bar(s); //copy >bar(move(s)); //move >//s has now been moved out of > > >//use-case: moving a value into place >void MyClass::MyClass(std::string s) >{ > //move value from s into default constructed member s_ > move(s, s_); >} > >Note that the combination of both moving a value to a function/ctor and >then moving it into place, e.g., > >std::string lv; >//... > >MyClass mc(move(lv)); > > >effectively results in a zero-copy invocation, with just a small number of >fixed size swap, default ctor and shallow dtor calls, so this is pretty >efficient. >//use-case: moving a temporary into an lvalue >std:: string lv; >move(foo(), lv); > > >> - Jeff >Tom Tom

1 0

Re: [boost] [non-instrusive move] interest in new library?
by Thomas Jordan 11 Jan '13

11 Jan '13

Joseph Gauterin wrote: > Out of curiosity, how are you detecting if a member function swap exists? >> it detects at compile-time if the type of the >> argument(s) has a member swap function //Type trait to determine whether a type has a swap() member function //Uses SFINAE and the "sizeof trick" from the book "C++ Template Metaprogramming" //by Abrahams and Gurtovoy template<typename T> struct has_swap { typedef char yes; typedef char (&no)[2]; //SFINAE eliminates this when the type is invalid template <typename U, U> struct Check; //this overload will be selected if the Check type is valid template <typename U> static yes Tester(Check<void(U::*)(U&), &U::swap>*); //overload resolution prefers anything at all over ... template <typename U> static no Tester(...); static bool const value = sizeof(Tester<T>(0)) == sizeof(yes); }; > > In general, there's no way of knowing if a member swap function is > more efficient than a single assignment. It isn't even for all the > examples you gave - boost::array<T,N>::swap performs N boost::swaps, > which, if T doesn't provide an efficient swap, results in N calls to > std::swap, and 3*N assignments. In general I'm wary of using swap in a > generic context unless the intent is to swap (i.e. not as a potential > optimization of assignment). Thanks, point taken. I've responded to the exact same point in Jeffrey Lee Hellrung Jr.'s comment on my original post, and also made some alternative suggestions. Would certainly appreciate any further feedback you have there.

1 0

Boost.Exception and constexpr
by Marshall Clow 10 Jan '13

10 Jan '13

I was playing around with Boost.Array tonight, seeing if I could make the signatures more closely match std::array. Specifically, I wanted to add 'constexpr' to "operator [] (size_t) const" and "at (size_t) const"as proposed in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3470.html But I ran into a problem. Here are the implementations: const_reference operator[](size_type i) const { BOOST_ASSERT_MSG( i < N, "out of range" ); return elems[i]; } const_reference at(size_type i) const { rangecheck(i); return elems[i]; } static void rangecheck (size_type i) { if (i >= size()) { std::out_of_range e("array<>: index out of range"); boost::throw_exception(e); } } BOOST_ASSERT does not fit into the constexpr world at all, and neither does rangecheck. I could rewrite rangecheck so it could be constexpr, but only (I believe) by throwing the exception directly, rather than using boost::throw_exception. static void rangecheck (size_type i) { if (i >= size()) throw std::out_of_range e("array<>: index out of range"); } or even just: BOOST_CONSTEXPR const_reference at(size_type i) const { return i >= size () ? throw std::out_of_range e("array<>: index out of range") : elems[i]; } Has anyone put any effort into making Boost.Exception (and BOOST_ASSERT) work with constexpr? -- 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

6 22

Re: [boost] [mailman] trouble with list subscription
by Eric Niebler 10 Jan '13

10 Jan '13

Thanks for your timely response, DongInn. No worries, **it happens. Eric On 1/10/2013 11:47 AM, DongInn Kim wrote: > OK, guys. It seems to be back to normal. > > I am sorry for all the inconveniences and troubles with the mailman websites. > > Regards, > > -- > - DongInn > > On Jan 10, 2013, at 2:34 PM, Marshall Clow wrote: > >> >> On Jan 10, 2013, at 11:19 AM, DongInn Kim <dikim(a)cs.indiana.edu> wrote: >> >>> I am sorry for this. I am working on it. I will be back with you guys soon. >> >> Thank you! >> -- Marshall >> >>> On Jan 10, 2013, at 2:18 PM, Marshall Clow wrote: >>> >>>> I'm seeing this too >>>> -- Marshall >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: Eric Niebler <eric(a)boostpro.com> >>>>> Subject: [boost] [mailman] trouble with list subscription >>>>> Date: January 10, 2013 10:46:39 AM PST >>>>> To: Boost mailing list <boost(a)lists.boost.org>, DongInn Kim <dikim(a)osl.iu.edu> >>>>> Reply-To: boost(a)lists.boost.org >>>>> >>>>> Many of the subscription links on >>>>> <http://www.boost.org/community/groups.html> are currently taking me to >>>>> a mailman error page. See for instance >>>>> <http://lists.boost.org/mailman/listinfo.cgi/boost>. I'm guessing this >>>>> has to do with the recent upgrade of the mailman software that DongInn >>>>> did. Does something need to change on the Indiana side, or are our links >>>>> out of date?

1 0

[mailman] trouble with list subscription
by Eric Niebler 10 Jan '13

10 Jan '13

Many of the subscription links on <http://www.boost.org/community/groups.html> are currently taking me to a mailman error page. See for instance <http://lists.boost.org/mailman/listinfo.cgi/boost>. I'm guessing this has to do with the recent upgrade of the mailman software that DongInn did. Does something need to change on the Indiana side, or are our links out of date? -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [non-instrusive move] interest in new library?
by Joseph Gauterin 10 Jan '13

10 Jan '13

Out of curiosity, how are you detecting if a member function swap exists? >it detects at compile-time if the type of the >argument(s) has a member swap function In general, there's no way of knowing if a member swap function is more efficient than a single assignment. It isn't even for all the examples you gave - boost::array<T,N>::swap performs N boost::swaps, which, if T doesn't provide an efficient swap, results in N calls to std::swap, and 3*N assignments. In general I'm wary of using swap in a generic context unless the intent is to swap (i.e. not as a potential optimization of assignment). >The library is non-intrusive and generic, it will perform an efficient move >in terms of swap for any type providing a member >swap operation, e.g, std::vector, boost::array, user-defined types etc.

1 0

Re: [boost] (Boost) QVM update
by Shakti Misra 09 Jan '13

09 Jan '13

Hi Emil, I also am waiting to try it out. My environment doesn't allow me to use boost completely. I may be getting little greedy, but any chance of using vectorization? :) ~Thanks Shakti On Wed, Jan 9, 2013 at 11:30 AM, Nathan Crookston < nathan.crookston(a)gmail.com> wrote: > Hi Emil, > > Emil Dotchevski wrote: > > > Boost QVM has been updated. Note, this library has not been reviewed > > yet and it is not part of Boost. > > > > Comments and bug reports are appreciated. > > > > I've been looking forward to this library. I often need something like > this in my work (mixture of graphics programming, image processing, and > geospatial applications). I wasn't happy with what ublas offered in the > static-sized 3-8 dimensions, so I rolled my own -- I'd be much happier to > have something like this, though. > > The documentation seem especially complete. A few questions and comments > that occurred to me as I was reading through (and occasionally glancing at > the code): > > * I'm sure [qvms]_traits is used all over the place, but I'd still rather > see scalar_traits, vector_traits, etc., especially as those may be > specialized by the user. > > * I thought s_traits was hard to find in the 'Generic programming > utilities' section. Should it be in the 'Type traits' section instead? > > * It looks like matrix types (probably vectors and quaternions too) must be > default constructible (for both make and the template conversion operator > of mat), though I didn't see that particular requirement noted -- am I > mistaken? > > * The SFINAE page seems to reference itself: > > sfinae > The boost::qvm::sfinae namespace contains only function names that use > SFINAE <circular link>. The boost::qvm namespace contains all Boost QVM > type and function names. > > I would have expected it to link to an explanation of sfinae -- not > necessarily part of QVM's docs. > > * inverse: I was surprised to see that you're inverting using the matrix > of cofactors. For my personal education, why do you use that method -- is > it more stable or efficient than others? A home-rolled implementation I > did something like the following: > > //Solving Ax = b > matrix<float> A; > vector<float> b; > inverse_matrix<float> inverse_m = invert(m);//actually perform lu > decomposition > vector<float> x = inverse_m * b;//actually back-substitutes from lu matrix. > > In that case, I knew that I'd only ever multiply by a vector -- which > allowed me to use a method which is at least as efficient as matrix > inversion and more numerically stable. I'm not sure if an inverse_matrix > type would allow something like: > > matrix<float> A = ...; > inverse_matrix<float> B = ...; > auto C = A * B; > auto D = B * A; > to be computed as efficiently as if B were really just a matrix type. I > could look that up tomorrow, when I have a reference on the material. If > it is, I think it would be interesting to have inverse return a view_proxy. > > * I haven't looked, but I assume QVM is targeting cases where both matrices > fit into cache? Meaning, it doesn't worry about things like cache > blocking? > > * I think the swizzling code is interesting. The Accessing * Elements > pages aren't too informative, though. It would help me if those pages, in > the 'See also:' section, were to link to examples of their usage. > > * Further on swizzling -- when I'm dealing with OpenGL texture coordinates, > the canonical names for them are s, t, r and q. Is there an interface > whereby I could allow writing something like this? > > TexCoord tc1(1, 2, 0, .5); > TexCoord tc2 = tc1 % TSRQ; > > I don't know that I'll ever need such a thing -- this is mostly out of > curiosity. > > I haven't had a chance to try QVM out -- I'd like to work up examples with > e.g., std::array<float,4>, then something with boost::units types as the > scalar types. In fact, working with the latter would be a killer feature > from this library for me. I'll let you know what I find. > > Thanks again for making this library available! > > Nate > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

(Boost) QVM update
by Emil Dotchevski 09 Jan '13

09 Jan '13

Boost QVM has been updated. Note, this library has not been reviewed yet and it is not part of Boost. Boost QVM provides a set of generic functions for working with quaternions, and vector and matrix types of static size. All operations use a type-traits system, which enables types from other vector/matrix libraries to be integrated in a common type-safe interface. The current source code and documentation is available at http://www.revergestudios.com/boost-qvm. It contains minor bug fixes, and the following new features: - view proxies that negate matrix rows and columns (negr/negc) - view proxies that swap two rows or columns in a matrix (swapr/swapc) - functions for indexing at run-time of any vector or matrix object of arbitrary size. Comments and bug reports are appreciated. Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 2

[non-instrusive move] interest in new library?
by THOMAS JORDAN 09 Jan '13

09 Jan '13

Apologies, my previous email I sent incomplete by mistake, please ignore that in favour of the following: Hi, Would there be interest for Boost in a small library providing a simple, non-instrusive emulation of basic move semantics for C++03 (though one which could also be used without harm in a C++11 environment)? The library currently consists of a small number of 'move' function overloads, plus a trait class. It can be used to facilitate move semantics/efficient value-orientated software design in environments which lack, or forbid C++11 or other, more intrusive C++03-aware move libraries (e.g., old/buggy compiler, learning curve prohibitive, etc.). In conjunction it facilitates/forces copy-elision and return-value (RVO) optimisations in certain situations where they might otherwise not be feasible. It works as follows: it detects at compile-time if the type of the argument(s) has a member swap function, and if so, it performs a swap, otherwise it calls the regular assignment operator ('move if possible, copy otherwise'). It can be used to provide an emulation of: - move-assignment between lvalues - moving an rvalue to an lvalue - moving an lvalue to a temporary It also supports moving between built-in arrays. Example use-cases are (ignoring namespace): #include "non_intrusive_move.h" //returning a value std::string foo(std::string s) { //e.g., append something to s //... //compiler can perform rvo (compiler would likely not perform nrvo if just used 'return s;') return move(s); } //moving a value to a function/ctor, when the value is not required by the calling code after the //function/ctor call std::string s("hello"); void bar(std::string s){...} bar(s); //copy bar(move(s)); //move //moving a value into place void MyClass::MyClass(std::string s) { //move value from s into default constructed member s_ move(s, s_); } Note that the combination of both moving a value to a function/ctor and then moving it into place e.g., std::string lv; //... MyClass mc(move(lv)); //lv no longer needed effectively results in a zero-copy invocation, with just a small number of fixed size swap, default ctor and shallow dtor calls, so this is pretty efficient. //moving a temporary into an lvalue std:: string lv; move(foo(), lv); //nicer than foo().swap(lv) The moved-from value is left in a 'valid' but undefined state, i.e., it can be destructed, assigned/moved to, swapped, etc. The library is non-intrusive and generic, it will perform an efficient move in terms of swap for any type providing a member swap operation, e.g, std::vector, boost::array, user-defined types etc. It also performs an efficient move for built-in arrays. The library is header-only and currently depends only on boost::enable_if and boost::swap as external dependencies. It is portable between C++03 and C++11 and has a gentle learning curve - the code is brief and easy to understand (with possible exception of the traits class) - I think that is quite an important feature of the library. It might be feasible to add a few other things, e.g., move, move_backward algorithms. The library is not intended to be standard-compliant (though similar where possible), and is not intended to compete with a much richer, but 'intrusive' library like Boost.Move. I've called it 'non-intrusive move' for the moment but it could of course be called something else (e.g., simple_move). Regards, Tom

2 1

Boost.Logging 1.51 Using VS2012.
by syvyi 09 Jan '13

09 Jan '13

Hello, my application which was successfully compiled on VS2010 brings the next errors using VS2012 c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(227): error C2664: 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::basic_attribute_set<CharT>::insert(const std::pair<const boost::log_mt_nt5::basic_slim_string<CharT>,boost::log_mt_nt5::basic_attribute_set<CharT>::mapped_type> )' : cannot convert parameter 1 from 'std::pair<_Ty1,_Ty2>' to 'const std::pair<_Ty1,_Ty2> &' 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char 4> ] 4> and 4> [ 4> _Ty1=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, 4> _Ty2=boost::shared_ptr<boost::log_mt_nt5::attribute> 4> ] 4> and 4> [ 4> _Ty1=const boost::log_mt_nt5::basic_slim_string<char>, 4> _Ty2=boost::log_mt_nt5::basic_attribute_set<char>::mapped_type 4> ] 4> Reason: cannot convert from 'std::pair<_Ty1,_Ty2>' to 'const std::pair<_Ty1,_Ty2>' 4> with 4> [ 4> _Ty1=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, 4> _Ty2=boost::shared_ptr<boost::log_mt_nt5::attribute> 4> ] 4> and 4> [ 4> _Ty1=const boost::log_mt_nt5::basic_slim_string<char>, 4> _Ty2=boost::log_mt_nt5::basic_attribute_set<char>::mapped_type 4> ] 4> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(226) : while compiling class template member function 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>::add_attribute_unlocked(const std::basic_string<_Elem,_Traits,_Alloc> &,const boost::shared_ptr<T> &)' 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> _Elem=char, 4> _Traits=std::char_traits<char>, 4> _Alloc=std::allocator<char>, 4> T=boost::log_mt_nt5::attribute 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\severity_feature.hpp(188) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>::add_attribute_unlocked(const std::basic_string<_Elem,_Traits,_Alloc> &,const boost::shared_ptr<T> &)' being compiled 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> _Elem=char, 4> _Traits=std::char_traits<char>, 4> _Alloc=std::allocator<char>, 4> T=boost::log_mt_nt5::attribute 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\channel_feature.hpp(212) : see reference to class template instantiation 'boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>' being compiled 4> with 4> [ 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(315) : see reference to class template instantiation 'boost::log_mt_nt5::sources::channel<ChannelT>::apply<BaseT>' being compiled 4> with 4> [ 4> ChannelT=std::string, 4> BaseT=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : see reference to class template instantiation 'boost::log_mt_nt5::sources::aux::inherit_logger_features::apply<PrevT,T>' being compiled 4> with 4> [ 4> PrevT=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled 4> with 4> [ 4> F=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> T1=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T2=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(81) : see reference to class template instantiation 'boost::mpl::apply2<F,T1,T2>' being compiled 4> with 4> [ 4> F=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> T1=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T2=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\reverse_fold.hpp(41) : see reference to class template instantiation 'boost::mpl::aux::reverse_fold_impl<N,First,Last,State,BackwardOp,ForwardOp>' being compiled 4> with 4> [ 4> N=2, 4> First=boost::mpl::v_iter<boost::mpl::vector2<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>,0>, 4> Last=boost::mpl::v_iter<boost::mpl::vector2<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>,2>, 4> State=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> BackwardOp=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> ForwardOp=boost::mpl::arg<1> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(338) : see reference to class template instantiation 'boost::mpl::reverse_fold<Sequence,State,BackwardOp>' being compiled 4> with 4> [ 4> Sequence=boost::log_mt_nt5::sources::features<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>, 4> State=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> BackwardOp=boost::log_mt_nt5::sources::aux::inherit_logger_features 4> ] 4> d:\sankom\manster\manster\manster\manster_logger.h(160) : see reference to class template instantiation 'boost::log_mt_nt5::sources::basic_composite_logger<CharT,FinalT,ThreadingModelT,FeaturesT>' being compiled 4> with 4> [ 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> FeaturesT=boost::log_mt_nt5::sources::features<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>> 4> ] What is the solution ? -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Logging-1-51-Using-VS2012-tp464114… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 7

Requesting permission to merge 82408 to release
by Glen Fernandes 09 Jan '13

09 Jan '13

82408 is a fix for #7867 (found by Mathias) where BOOST_NO_EXCEPTIONS was not honored. Glen

2 1

[non-instrusive move] interest in new library?
by THOMAS JORDAN 09 Jan '13

09 Jan '13

Hi, Would there be interest for Boost in a small library providing a simple, non-instrusive emulation of move semantics for C++03 (though it could also be used in a C++11 environment)? It consists of a small number of 'move' function overloads, plus a trait class. It can be used facilitate move semantics/value-orientated programming in environments which lack/forbid C++11 or intrusive move libraries, and facilitate/force copy-elision and RVO optimisations in certain situations where they might otherwise not occur. Its mechanism is as follows: it detects at compile-time if the type of the argument(s) has a member swap function, and if so, it performs a swap, otherwise is calls the regular assignment operator. It can be used to provide an emulation of: move-assignment between lvalues moving an rvalue to an lvalue moving an lvalue to a temporary. It also supports moving between built-in arrays. Example use-cases are: //returning a value std::string foo(std::string s) { //append something to s //... //compiler can perform rvo, if just used 'return s;' compiler would not perform nrvo return move(s); } //passing a value std::string s("hello"); void bar(std::string s) {...} foo(s); //copy foo(move(s)); //move //moving a value into place void MyClass::MyClass(std::string s) { //move value into default constructed member move(s, s_); }

1 0

[log] v2 beta 1 mini-review request
by Andrey Semashev 09 Jan '13

09 Jan '13

Hi, It's been a while since Boost.Log v1 was reviewed back in 2010. Here is the review result: http://lists.boost.org/boost-announce/2010/03/0256.php But the time was spent for purpose as the library took substantial changes. I've just uploaded the v2 beta 1 to the SourceForge project page: Code: http://sourceforge.net/projects/boost-log/files/boost-log-2.0-beta1-r800.zi… Docs: http://boost-log.sourceforge.net/libs/log/doc/html/index.html SVN: svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log I must say this is not the final release; the docs are not quite complete (in particular, the Extending the library section has not been updated yet) and the code may have rough edges here and there. But it is good enough to review the changes, or the whole library if you haven't got acquainted with v1. The change log is quite big, you can see it here: http://boost-log.sourceforge.net/libs/log/doc/html/log/changelog.html I'll just mention the most significant highlights here: - Character type support unified. Log records, core, filters and most sinks have been made character type agnostic. It is possible now to emit log records with messages with different character types in a single application. Character code conversion will be performed as needed when formatting log records. - Filters and formatters were rewritten and are now based on Boost.Phoenix. Unified attribute value placeholders in filters and formatters. The template expressions now reside in the common namespace "expressions". - Added support for attribute keywords in filters and formatters. Attribute keywords identify particular attribute values within log records; their use significantly simplify template expressions syntax. - Reworked attribute value extraction. In fact, the old extraction API has been split into visitation and the new extraction APIs. In conjunction with attribute keywords this makes extracting attribute values very simple. - Introduced a concept of a default sink which is used when no sinks are registered in the logging core. The sink outputs formatted log records to the console. - Trivial logging now outputs to console by default. Actually, trivial logging logs to the default sink by default. - Asynchronous sink now supports customizing record queueing strategies. New bounded queue strategies solve the problem of log records piling in the queue. - Attributes are now implemented following the pimpl pattern; it is no longer needed to create attributes using make_shared or new. This simplified attribute registration code. - Channel logger now allows changing channel name after construction. I don't plan any major changes to the code until the final release, unless something critical comes up during the review. I will keep updating the docs in the coming days and will request permission to merge to Boost when done. Comments are welcome.

3 4

[interprocess] (OS X) waiting on condition variable = CPU 100% + fans running loud
by Francisco Lopes 08 Jan '13

08 Jan '13

Hi, I was implementing a kind of server using shared memory. The server should keep idle, waiting for a request and I do this by waiting on a condition variable, of course. I then noticed my fans running high when I let the server waiting a little longer while testing and discovered this happens simply because of some busy loop implementation for condition waiting. Is there any reason for that? Given the interprocess library age, there's no way for implementing a non-busy interprocess condition variable waiting available? https://svn.boost.org/trac/boost/ticket/6108 Regards, Francisco Lopes

6 15