- Boost - lists.boost.org

[quickbook] Using .. for content in templates
by Andreas Pokorny 24 Jan '13

24 Jan '13

Hi, We now integrated plantuml into the quickbook / docbook - toolchain. plantuml uses text based inputs to declare UML diagrams. Some of the text markups include "..". For embedding the diagrams directly inside the document source we use: [template plantuml[filename scale text] '''<mediaobject><imageobject><imagedata fileref="'''[filename]'''" sclae="'''[scale]'''"/> </imageobject> <textobject><![CDATA[ @startuml ''' [filename]''' ''' [text] ''' @enduml ]]> </textobject> '''] and just call plantuml on the output of quickbook. So the user calls [plantuml my_diag.svg..60..''' Foo --> Bar Blub ..> Bar '''] An extended variant also combines everything into a docbook figure.. To bypass the issue I now consider splitting up the call into two templates, and not passing the plantuml content through the template calls.. Are there any other solutions possible? regards Andreas

2 7

[geometry] latest extensions
by Andrew Hundt 24 Jan '13

24 Jan '13

Where are the best places to get the latest and the latest stable Boost.Geometry extensions? I found the following location: https://svn.boost.org/svn/boost/sandbox-tags/geometry/boost-geometry-0.9.0/ But I'm not sure if it is current or out of date. Unless I missed it, perhaps some link or note in the Boost.Geometry docs on the best place to acquire extensions would be valuable? I assume such a link would include the usual warning that extensions are not accepted and are subject to change. Cheers! Andrew Hundt

2 1

(no subject)
by Achilleas Margaritis 24 Jan '13

24 Jan '13

http://drstarwynn.com/wp-content/plugins/akismet/yahool221.php

1 0

[crc] Missing reflector<>::reflect( ) on trunk
by Fernando Pelliccioni 23 Jan '13

23 Jan '13

Hi Daryle, hi all, I am using the Hamigaki Archivers library ( http://hamigaki.sourceforge.jp/) This library depends on Boost.Crc. Somewhere in the code there is something like ... boost::detail::reflector<32>::reflect(0x12345678); This compiles fine using Boost 1.52.0, but fails using Boost Trunk. The following code part does not exist anymore in boost/crc.hpp ( on the Trunk ) ... // Function that reflects its argument template < std::size_t Bits > typename reflector<Bits>::value_type reflector<Bits>::reflect ( typename reflector<Bits>::value_type x ) { value_type reflection = 0; value_type const one = 1; for ( std::size_t i = 0 ; i < Bits ; ++i, x >>= 1 ) { if ( x & one ) { reflection |= ( one << (Bits - 1u - i) ); } } return reflection; } Is there any replacement? Thanks and regards, Fernando P.

2 5

[atomic] [release] possible linking problem with atomic (was: [1.53.0] Beta release candidates available)
by Eric Niebler 22 Jan '13

22 Jan '13

Fwd'ed from the users list... On 1/10/2013 9:37 AM, Olivier Tristan wrote: > Hi, > > Don't know if It's suppose to be normal but it looks that the newly > added boost atomic requires linking against a static lib by default. > This seems wrong as this an header only package. > > Please note that I'm using a fresh 1.53 beta 1 with no define like > BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK > > BOOST_DYN_LINK is greyed out when I open the header in the editor so > it doesn't look like to be defined. > > (Visual c++ 2005 SP1) > > Am I missing something here ? > > Thanks !

8 16

Query of Interest in annotated tree extensions to Boost.Intrusive
by Jeff Snyder 22 Jan '13

22 Jan '13

Hi All, I've been working on some extensions to allow users to add annotations to tree data structures (explanation of the idea here: http://je4d.blogspot.co.uk/2013/01/boostintrusive-annotated-trees-part-1.ht…) This isn't a new library submission, but it's a fairly substantial modification to Boost.Intrusive, so I've got the following questions on my mind: 1. Is there interest in having such functionality in boost? 2. If so, should the changes go through the formal review process? Regarding the level of interest: To the best of my knowledge, no one has yet released a library that provides this functionality. I have, however, come across a few things that indicate that the technique is in use: http://is.gd/PA1Lhm (Evidence of demand for such a library) http://is.gd/Lepzrq (A binary tree with a 'pixel height' annotation) http://is.gd/PMb6Fy (A node-count annotation on B-trees) http://is.gd/RHjpeQ (Paper about a "count" annotation on suffix trees) http://is.gd/lHVhC0 (About the usefulness of annotations. Separates the data from annotations, unlike the proposed library) Many thanks, Jeff Snyder (aka je4d)

6 9

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

21 Jan '13

Jeffrey Lee Hellrung, Jr. wrote > > On Wed, Jan 9, 2013 at 3:35 AM, THOMAS JORDAN <tomjordan766(a)gmail.com>wrote: > >> 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. > > 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. For a type with an expensive swap, performance would be suboptimal. The library checks at compile-time whether the element type of the boost array has a swap member, and calls array.swap if true, and copies otherwise (recursively if the element type is also a boost array). However, the user would need to write an overload for a type with an expensive member swap, which precludes the true generic context. So yes, it is more aimed at situations where you have pretty firm knowledge of the types you will be using. This would either require a really strong caveat emptor or may not be acceptable for release into the wild? 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){} friend void swap(MyClass& a, MyClass& b) { //efficient swap member } 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. 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

2 3

[Release][Spirit] Asking for permission to merge a bugfix
by Hartmut Kaiser 20 Jan '13

20 Jan '13

Dear release managers, I would like to ask for permission to merge a changeset: Revision: 82521 Author: hkaiser Date: Thursday, January 17, 2013 7:33:58 AM Message: Fix #7900: karma indirect_iterator returns reference to temporary ---- Modified : /trunk/boost/spirit/home/karma/detail/indirect_iterator.hpp Modified : /trunk/libs/spirit/test/Jamfile Added : /trunk/libs/spirit/test/karma/regression_iterator.cpp I committed a couple of days ago in order to fix a newly discovered bug. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[variant] Basic rvalue and C++11 features support
by Antony Polukhin 20 Jan '13

20 Jan '13

Hi, There is a patch in ticket #7620 that adds some rvalue assignment operators and rvalue constructors for Boost.Variant library. I saw no activity from authors of Boost.Variant Eric Friedman and Itay Maman for a long time, so if there will be no objections, I'll commit patch to trunk in the middle of November. Any suggestions and comments are welcomed. -- Best regards, Antony Polukhin

19 74

permission to merge documentation
by Oliver Kowalke 20 Jan '13

20 Jan '13

I'd like to ask for permission to update the documentation of boost.coroutine. Oliver

2 1