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

Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
by Matthew Chambers 26 Jan '12

26 Jan '12

On Oct 13, 2011 Michel Morin wrote: > lexical_cast made optimizations for some types (such as `std::string`) > to achieve better performance. But, from my experience, > it seems that lexical_cast does not make any optimization for > `boost::iterator_range<std::string::iterator>`. > > Is there any plan to add optimization for such iterator ranges? > Currently, > - `lexical_cast<int>(std::string(iter_rng.begin(), iter_rng.end()))` > is faster > than `lexical_cast<int>(iter_rng)`. > - Assuming it is safe to use `std::atoi`, > `std::atoi(&iter_rng.front())` is faster > than both of the above two methods. > (`iter_rng` is an instance of `boost::iterator_range<std::string::iterator>`.) > > Regards, > Michel This post was on the boost users list but never got a reply. I figure it might be a better fit on the developer list. I too would like to see optimized conversions work on string ranges; what's the point in doing a fast conversion if you have to do a string copy first? :) -Matt

8 16

[quickbook] changing paths
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, How can I change the paths were Boost.QuickBook looks for the following files? 1) CSS and icon images by default from BOOST_ROOT/doc. 2) Navigation bar by default from BOOST_ROOT/tools/boostbook/xls. Essentially, I'd like to put the CSS, icon images, and navbar into a different path. Also, I'd like to change the navbar to one of my own. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-changing-paths-tp3925967… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 4

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

Is there any interest in command line interpreter class templates?
by alexey.tsoy 29 Dec '11

29 Dec '11

Hello everybody, The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation. The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent. The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it. Regards Alexey -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[concept_check] Some issues
by Robert Kawulak 23 Dec '11

23 Dec '11

Hi, I've spotted some problems when playing with BCCL: - The implementation of assignable_archetype defines private default and copy constructors, so for example assignable_archetype<copy_constructible_archetype<>> will not actually be copy constructible. The same for convertible_to_archetype and convertible_from_archetype, but additionally with copy assignment. Is this by purpose? - copy_constructible_archetype defines public default constructor - again, am I overlooking something or it should not be there? - Function and predicate archetypes also seem to provide too wide interface (they are copy constructible and assignable). Additionally, they don't allow for archetypes chaining since they lack the Base parameter (with the only exception of binary_predicate_archetype - why the inconsistency?) - Apart from the provided function object concepts and archetypes it seems it would be useful to have a general Callable concept and the corresponding callable_archetype, parameterised with the types of arguments and return value. Wouldn't it be valuable to add them? - There's boost/concept_check directory in the trunk - are the files in it actually used anywhere? I've found no reference to them in Boost headers, documentation doesn't mention them too. Best regards, Robert

3 10

boost and google search
by Edward Rankin 23 Dec '11

23 Dec '11

Hi, I am sure it is pretty common for users of boost to use google to search for documentation/tutorials on their favorite library in boost. I have found that the top hits are typically not the latest documents. For example I just searched for boost,foreach and a documentation from 1.35 was the first hit. It would be great if there is a way to tell google to update their links to the latest version. Anyone knows whether this is possible, and how to make it happen? This problem probably applies to any search engine but I can only comment on google search. Thanks, Edward

11 23

[1.48.0] Beta 1 release candidates available
by Beman Dawes 20 Dec '11

20 Dec '11

Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

21 44

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 18 Dec '11

18 Dec '11

On 24 Nov 2011 09:11:19 Joel de Guzman wrote: >Man! Of course you should use the examples in 1.45. Those examples >are for 1.48 and uses new features implemented in 1.48! Sheesh! I fully understand that. The point is that the Phoenix interface is evolving much more quickly than that of probably any other Boost library. Even apart from the fact that there already have been two bottom-up rewrites, there are enough significant changes between point releases that even small example programs are tied to a particular version of the library. Why is the optimal way to write a small calculator example today so different from the optimal way to write it six months ago? I'm not disputing that you're making forward progress, just highlighting this as another barrier to entry that Local likely won't have. >Double Sheesh! If you've spent even a few seconds looking into the >error (beyond fault-finding), you will see that a simple textual >search of "error" will reveal this: Yes, it's possible to wade through the error messages and figure out what went wrong. And Qi is clearly trying to help out with traceable assertions; that may well be the best we can do. But no reasonable person would claim that hundreds of lines of error message, mostly filled with types that the user never directly constructed, are the most desirable way to report a simple syntax error. This problem is endemic to all ET libraries and compilers, and it would be very, very hard to do much better. Again, though, I think you're underselling this as a barrier to entry. How many people would ever learn C++ if all libraries did this? >Now having said that, and before I leave this thread, let me remind >everyone that **you can also have statement syntax in Phoenix** if you >have a complex statement and you fear writing complex phoenix lambda >expressions. It's called phoenix::functions. The important issue here isn't just statement /syntax/, it's that we have options available that don't turn what looks like an ordinary C++ statement into a massive AST with its own mini-compiler behind the scenes.

18 38