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

BoostCon video mirror
by Jeroen Habraken 23 May '11

23 May '11

Hi, After becoming annoyed with blip.tv I've created a mirror of the BoostCon videos with the help of Nikhef (http://www.nikhef.nl/en/) It can be found at http://wipkip.nikhef.nl/events/BoostCon/2010/ and there's a quick overview over at http://vexocide.org/boostcon.html. If desired we'll gladly host the 2011 videos as well. Regards, Jeroen Habraken

1 0

[process] boostcon code now on github
by Jeff Flinn 22 May '11

22 May '11

The source code as presented at the boostcon "Boost Process" session is now available at: https://github.com/JeffFlinn/boost-process Let me know if there are any problems accessing this as I'm a github newbie. Thanks, Jeff

1 0

[btree] Status report
by Beman Dawes 22 May '11

22 May '11

The slides for my BoostCon "Proposed Boost B-tree Library" presentation are available: http://github.com/boostcon/2011_presentations/raw/master/tue/proposed_b_tre… Please be aware that while the library is progressing nicely, it isn't ready for production use: * There are outstanding bugs, particularly with variable length data. * Names and signatures may still change. * Documentation is barely started. * Build is failing on Mac OS X. That probably won't get fixed until after BoostCon. (Reported by Marshall Clow) That said, the response to the presentation was very positive and I'm actively continuing development. Anyone interested in the library is encouraged to take a look and give it a try. See http://github.com/Beman/Boost-Btree/blob/master/README for install instructions. Feedback welcome! Thanks, --Beman

5 12

Invitation to connect on LinkedIn
by Илья Биин via LinkedIn 21 May '11

21 May '11

LinkedIn ------------Илья Биин requested to add you as a connection on LinkedIn: ------------------------------------------ Yuriy, I'd like to add you to my professional network on LinkedIn. - Илья Accept invitation from Илья Биин http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… View invitation from Илья Биин http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… ------------------------------------------ DID YOU KNOW that LinkedIn can find the answers to your most difficult questions? Post those vexing questions on LinkedIn Answers to tap into the knowledge of the world's foremost business experts: http://www.linkedin.com/e/bv6hcz-gnyytzl3-3y/ask/inv-23/ -- (c) 2011, LinkedIn Corporation

1 0

Invitation to connect on LinkedIn
by Serge Blazhievsky 21 May '11

21 May '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Serge Serge Blazhievsky Staff Software Engineer at LiveOps San Francisco Bay Area Confirm that you know Serge Blazhievsky https://www.linkedin.com/e/bv6hcz-gny8eb0s-6p/isd/2953122588/yo_3A_ww/ -- (c) 2011, LinkedIn Corporation

2 1

Boost statechart viewer
by Petr Šilhavík 20 May '11

20 May '11

Dear Boost-Statechart developers and users, I would like to ask you to try the tool that I am developing in my bachelor thesis and give me your opinion about it. The tool is able to visualize state machines that use Boost-Statechart library. It uses Clang and LLVM *(version 2.9)* for producing the output files that can be visualized using dot. Now it can work with states (not the orthogonal states), transitions and custom reactions. You can find more information about it on the web page of this project where you can also download the source codes and see some examples of the output pictures. http://rtime.felk.cvut.cz/statechart-viewer/ I am looking forward to your answers. Best regards Petr Silhavik

4 11

[Unicode] Library info
by Mathias Gaunard 20 May '11

20 May '11

Just a remainder for people that followed my Unicode presentation at Boostcon: Library is available on the Boost Sandbox: <https://svn.boost.org/svn/boost/sandbox/SOC/2009/unicode> Documentation is available here: <http://mathias.gaunard.com/unicode/doc/html/>

2 4

How to inspect state of boost::mt19937?
by Matthew Gwynne 20 May '11

20 May '11

Hi, Does anyone know how I can access the internal state of the Mersenne twister (boost::mt19937) easily? That is the 623 state bytes. I am looking to initialise a random number generator and then inspect the state to compare it to another system which apparently implements MT19937 but gives different results. If someone could point me in the right direction, that would be great! Thanks! Matthew Gwynne http://cs.swan.ac.uk/~csmg/

2 2

Generic try, catch in boost::lexical_cast
by Jeroen Habraken 20 May '11

20 May '11

Hi, Whilst updating SVN today I spotted a change to boost::lexical_cast, https://svn.boost.org/trac/boost/changeset/71958, which introduces a try { } catch(...) { } construction. I'm curious as to why this catch-all is needed since it seems to be there to deal with boost::numeric_cast exceptions and whether it could lead to a std::bad_alloc being rethrown as a bad_lexical_cast. Kind regards, Jeroen Habraken

3 5

[local] this_ or _this?
by Lorenzo Caminiti 19 May '11

19 May '11

Hello all, Boost.Local uses a special name `this_` to access the object `this` bound from the enclosing scope. Shall this name be `this_` or `_this` according to Boost practices? struct c { void g(int x) { ... } void f() { void BOOST_LOCAL_FUNCTION_PARAMS( (int x) (bind this) ) { this_->g(x); // <<<<<<<<< Shall this be `_this->g(x);` instead? ... } BOOST_LOCAL_FUNCTIO_NAME(l) ... } ... }; In particular, some library uses _ postfix for statements like mpl::if_ (not mpl::_if) while other uses _ prefix for variables like phoenix::local_names::_f (not local_names::f_). Thanks a lot. -- Lorenzo

12 21

Forum created for IDL to C++0x work
by Johnny Willemsen 19 May '11

19 May '11

Hi, Last year I posted on the boost list about ideas for a new IDL to C++0x language binding for CORBA/CCM/DDS. The OMG has issued a RFP for this (see www.omg.org) In order to share technical ideas, we have opened a forum on http://www.orbzone.org, the community portal for Corba, CCM, and related middleware technologies. If you have any ideas, please share them on ORBzone. Regards, Johnny Willemsen Remedy IT

1 0

anonymous svn checkout
by Mathieu Champlon 19 May '11

19 May '11

Hi, http://svn.boost.org/svn/boost seems to be asking for credentials, is it on purpose ? Thanks, MAT.

1 1

Fwd: [ICL] some improvement proposals
by Denis 19 May '11

19 May '11

Hi 1. (questionable because it changes the visible interface): rename `left_open` and `right_open` to `right_closed` and `left_closed`. Reason: interval_bounds is used in bitwise operations with bit=1 means `closed`. `left_closed() | open()` resulting in `left_closed()` is more readable than `right_open() | open()` resulting in `left_closed()`. Also, there are checkers `is_left_closed()` and `is_right_closed()` but not for *_open I had to use `class bounded_value` in my program (as in Icl details: calculating lower and upper bound of interval separately, then constructing the interval, bitwise or'ing bounds) and I commented every usage of `right_open()` as `left closed` in order to explain why I use `interval_bounds::*right*_open()` in constructing the *left `*bounded_value` of the interval. This resulted in the idea of renaming. Maybe making bit=1 mean `open` would be less painful for other users ? 2. define `contains(interval, elt)` as `!below(interval, elt) && !above(interval, elt)` allowing the user to use `below()` and `above()`. Sometimes it is useful. Anyway, all the versions of `contains()` are made of checking for both bounds. 3. It would nice if the functions taking two intervals will have versions taking an element as second argument. I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all the list at the moment) Constructing temporary `close_interval` object in order only to pass it into those functions is cheap with ints but would be expensive with heap-allocated domains (blobs, strings, etc).

1 0

[iostreams] OK to patch Mac OS X config problem?
by Beman Dawes 19 May '11

19 May '11

The following path fixes a problem that causes a B-tree compile failure on Mac OS X. Does anyone know any reason not to apply this? --Beman PS: Thanks to Marshall Clow for testing this. --- C:\Users\Beman\AppData\Local\Temp\rtl.hpp-revBASE.svn000.tmp.hpp 2011-05-18 22:23:07.000000000 -0400 +++ C:\boost\trunk\boost\iostreams\detail\config\rtl.hpp 2011-05-18 22:21:21.000000000 -0400 @@ -42,13 +42,13 @@ # define BOOST_IOSTREAMS_FD_OFFSET __int64 # else // Borland, Metrowerks, ... # define BOOST_IOSTREAMS_FD_SEEK lseek # define BOOST_IOSTREAMS_FD_OFFSET long # endif #else // Non-windows -# if defined(_LARGEFILE64_SOURCE) && \ +# if defined(_LARGEFILE64_SOURCE) && !defined(__APPLE__) && \ (!defined(_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64) || \ defined(_AIX) && !defined(_LARGE_FILES) || \ defined(BOOST_IOSTREAMS_HAS_LARGE_FILE_EXTENSIONS) /**/ /* Systems with transitional extensions for large file support */

1 0

[boostcon][proto] Suggestion for LIAW session: fixed-point numbers
by Ravi 19 May '11

19 May '11

Hi, Are there any proto-based ideas for the library-in-a-week sessions? If not, would building a fixed-point data type be of interest? The domain is narrow enough that something useful can be accomplished in 4 sessions, but of large enough scope to present opportunities for exploring proto in depth. A fairly simple design follows representing a number: fixed_number<int width, int ulp, // 2^{ulp} is the smallest increment possible bool signed, template assigner<first, last, signed> > 'assigner' handles rounding/truncation/wrapping/etc when assigning another number (floating-point or fixed-point) to the current one. Internally, each fixed-point number would be represented by a boost::uint64_t or a boost::int64_t (limiting the maximum precision allowed). As an example, fixed_number<5, -3, false> would represent a data type that would go from 0 to 3.875 in steps of 0.125. Proto would be used for creating all arithmetic operations since the return type of a+b could be different from the type of either a or b. A bonus would involve getting the fixed-point data type to play well with std::complex (and, yes, I am aware that std::complex is not designed to work with anything other than double and float, and will require specialization in the std namespace). If there is sufficient interest, I could even provide a starting point with +,-,* implemented; / would take more time. The design above is intended as a starting point for discussion and I am most definitely not wedded to it. I am a tyro when it comes to proto, and hence would need someone with more proto expertise to guide the discussion. Regards, Ravi

8 24

[mutex] move / merge
by Phil Bouchard 18 May '11

18 May '11

Hi, Although Block Pointer is now thread safe it could use some optimization. To do so it'll need some special operations on mutexes such as move and merge. The operations need to be atomic as well. I was wondering if this was already attempted. Thanks, -Phil

5 15

Bug #3831
by Chris Wilson 18 May '11

18 May '11

Hi there, I'm attempting to use the JSON parser to read in a JSON file, but I am running up against the problem described in bug #3831<https://svn.boost.org/trac/boost/ticket/3831>, even though this bug has been marked as fixed. The milestone on the ticket is marked as 'Boost 1.42.0', but is has a score through it and I'm not sure if that means it's been fixed in that milestone or if it's been retargeted at a different milestone. I am using version 1.42.0-4ubuntu2 of the libraries so I am wondering if I have an outdated installation, or if there's another reason why I don't have the patched version. Can anyone shed some light this please? Thanks, Chris

3 3

[range] strange behavior of operator== with iterator_range
by Bryce Lelbach 18 May '11

18 May '11

Can someone tell me if the behavior demonstrated in the following program is intentional or a bug in Boost.Range? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

3 2

[chrono] Thread clock compatibility problems on Android
by Libor Bus 18 May '11

18 May '11

Hello, has anybody experienced also compatibility problems of chrono library on Android? I found following (Android 2.2, NDK-r5b, chrono v0.71, rev #71693): 1) Sources with boost::chrono::thread_clock does not compile, since _POSIX_THREAD_CPUTIME is not defined on Android. My workaround is to hack chrono/config.hpp: # if 1 //defined(_POSIX_THREAD_CPUTIME) # define BOOST_CHRONO_HAS_THREAD_CLOCK # define BOOST_CHRONO_THREAD_CLOCK_IS_MONOTONIC true # endif 2) ::clock_gettime() fails when called with clock ID got from pthread_getcpuclockid. My workaround is to call ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) in chrono/detail/inlined/posix/thread_clock.hpp. 3) Additionally there is precision problem on Linux platforms, stopwatch<process_cpu_clock> provides results with different units on Windows (nanoseconds) and Linux platforms (miliseconds). BR, Libor -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-Thread-clock-compatibility-proble… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 17

Re: [boost] Help on 2 key search
by Vicente Botet 18 May '11

18 May '11

Renee wrote: > > HiAll > Being a newbie i request your help. > > I have a emp database. I store them based on emp id as well as ssn and > need to store their extended details. What datatype is best used to store > this info. I need to search through millions of emp recs that can be > searched by either ssn or by emp id. do suggest. > some fields are as below: > emp id > ssn > emp first name > emp last name > emp sal > emp age > if we use map can have just one key value so it can be either ssn or emp > id. using 2 maps one for ssn and emp record and another for emp id and emp > record is not efficient as there are millions of records. > ur help is appreciated. will multi index help in this case. do suggest. > > -Renee > Hi, If you need to realize search based on these two fields MultiIndex seems the appropriated structure. If emp_id is an integer (unique) the use of a non-ordered index could give you better performances. The major problem is how to ensure this id is unique. I guess that ssn stands for Social Security Number, which is too big to fall on a builtin, so a string will be need. Again the use of a good hash could improve the performances. HTH, Vicente P.S. This kind of questions are better answered on the Boost User ML or even on Stack Overflow. -- View this message in context: http://boost.2283326.n4.nabble.com/Help-on-2-key-search-tp3530830p3531660.h… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[variant] static_visitor deadlock
by Andrew Hundt 17 May '11

17 May '11

I believe I may have found a way to create a deadlock in static_visitor, but it may be my own mistake. It seems if I apply one static visitor within another with an extra call to operator() that I use for shared_ptr objects, the program deadlocks in apply_visitor_binary_invoke::internal_visit(). The template in my class below is another static visitor object, so in essence I am creating an effect similar to a java decorator using visitors. Here is a stripped down version of the class with which the deadlock occurs: /** * @class VisitorDecorator * * @brief decorates (wraps) a normal visitor */ template <typename T> class VisitorDecorator : public boost::static_visitor<typename T::result_type> { typedef typename T::result_type t_result_type; public: VisitorDecorator(boost::shared_ptr<T> deviceCommandVisitor, std::string filename): m_visitor(deviceCommandVisitor), m_filename(filename) {} /** * @brief strip shared pointers and handle the object itself */ template <typename U, typename V> inline t_result_type operator()( boost::shared_ptr<U>& deviceP, boost::shared_ptr<V>& commandP){ return operator()(*deviceP,*commandP); } /** * @brief Connect the specified struct types to the log file */ template<typename U, typename V> t_result_type operator()(U& device, V& command){ return (*m_visitor)(device,command); } private: boost::shared_ptr<T> m_visitor; std::string m_filename; }; Does anyone have thoughts or suggestions, be it my fault or a bug in the library? Cheers! Andrew Hundt

1 1

[introductions]
by Gregory Crosswhite 17 May '11

17 May '11

Hey everyone! I don't know what the protocol is for this, but since I have been posting occasionally for a while and have offered to be a Review Manager but am relatively unknown to the community (which, again, means that I will completely understand and won't be offended in the slightest if you politely decline my offer to be a Review Manager :-) ) and have never introduced myself I figured that now might be as good a time as any: I am a graduate student who will be finishing up my PhD in Physics in the next month. My field is roughly quantum computing/quantum simulation, and my specialty is writing software that solves problems in the field of quantum error correction. My web page, which gives an overview of my background, is here: http://students.washington.edu/gcross/index.html Cheers, Greg

6 7

[multi_index] Extending multi_index_container hash tables
by Vladimir Voznesensky 17 May '11

17 May '11

Hello there. Another question. Why nodes with similar values are grouped sequentially in non-unique hash table? It's rather a strong restriction leading to extra iterations during insertions and modifications (please, see link_point and in_place methods in hashed_index.hpp). -vv

1 0

[review] Formal review of AutoIndex starts 5th May
by Daniel James 17 May '11

17 May '11

Hello everyone, The formal review of John Maddock's AutoIndex starts tomorrow, 5th May and finishes on Saturday 14th May. It's a little different to normal as it's a review of a documentation tool, rather than a library. We'll follow the normal procedure. Hopefully the review will also provide some experience for deciding how to deal with other tools in the future. About AutoIndex =============== The documentation describes it as "a tool for taking the grunt work out of indexing a Boostbook/Docbook document that describes C/C++ code". The documentation is online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html AutoIndex can be downloaded from the vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=auto_i… The download also contains a pdf of the documentation at 'doc/auto_index.pdf', and a copy of the html documentation at 'doc/html/index.html'. You can also see some examples of the indexes it generates, in a few libraries' documentation: http://www.boost.org/libs/spirit/ http://www.boost.org/libs/type_traits/ http://www.boost.org/libs/math/doc/sf_and_dist/html/ Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[autoindex]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. It's worth a look even if you don't use docbook or the boost documentation tools yourself. As someone who uses boost, the generated indexes are intended for your use so your views do matter. Even though this isn't a library, I think the (slightly modified) general guidelines still apply: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of AutoIndex? - Did you try to use it? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think that AutoIndex should be accepted into Boost? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More detail on the review process is available at: http://www.boost.org/community/reviews.html I think it should be made clear that if accepted, there won't be any requirement to use AutoIndex it. Thanks in advance, Daniel James AutoIndex Review Manager

6 11

[review][autoindex] AutoIndex review extended
by Daniel James 17 May '11

17 May '11

Hello all, The AutoIndex review is extended for another week, it's now running until Saturday 21st May. This will hopefully give people who have been busy preparing for boostcon a chance to review it in a quiet moment. I'm also interested in hearing from people who won't be using the tool directly, but might be using the indexes it generates. Or perhaps already are, since it's already been used for Boost.Spirit, Boost.Type Traits and Boost.Math: http://www.boost.org/libs/spirit/ http://www.boost.org/libs/type_traits/ http://www.boost.org/libs/math/doc/sf_and_dist/html/ It doesn't need to be a long or in depth review to be useful. The documentation is online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html AutoIndex can be downloaded from the vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=auto_i… thanks, Daniel James AutoIndex review manager

3 12

Boost talk / Funding / Your input is needed
by Ruediger Berlich 17 May '11

17 May '11

Dear all, at BoostCon 2011, I will give a presentation with the title and abstract: //---------------------------------------- Funding Boost development through national and international research programs and funds This presentation wants to start a discussion about possible ways of leveraging national and international research programs and funds to support Boost development. The goals are threefold: - To start and organize a joint effort in many countries to leverage national and international research funding schemes (e.g. NSF, European Union, …) for the benefit of Boost development - To make Boost a standard topic in the curricula of computer science education at universities and polytechnicals around the world - To involve new protagonists from the science community in Boost development //---------------------------------------- I think that this pretty much sums up what the presentation is about. I will, however, necessarily have to assume a (European and particularly German) view on this topic, as I have no experience with e.g. US academic funding schemes. The session is meant to be a brainstorming session and reality check; and without your input it will hardly be possible to fill 90 minutes for this topic. If you have first-hand experience with research grants and national or international funding schemes or if you have any related idea you would like to share, I particularly invite you to come along and contribute to the overall picture. I am sending this mail to the development list, as this is hardly a user- level issue. Thanks and maybe see you at the session, Ruediger Berlich

2 1

[Block Pointer] now thread safe!
by Phil Bouchard 17 May '11

17 May '11

Ok, Block Pointer is now thread safe! The following file was its test: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… It is now ready for a review. Thanks! -Phil

3 6

[siprit] Can't compile the following code with vs 2008
by 罗勇刚(Yonggang Luo) 16 May '11

16 May '11

/***************************************************************************** * * This file is part of Mapnik (c++ mapping toolkit) * * Copyright (C) 2009 Artem Pavlenko * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * *****************************************************************************/ //$Id$ #ifndef MAPNIK_EXPRESSIONS_GRAMMAR_HPP #define MAPNIK_EXPRESSIONS_GRAMMAR_HPP // mapnik #include <mapnik/value.hpp> #include <mapnik/expression_node.hpp> // boost #include <boost/version.hpp> #include <boost/variant.hpp> #include <boost/shared_ptr.hpp> #include <boost/concept_check.hpp> //spirit2 #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/qi_action.hpp> //fusion #include <boost/fusion/include/adapt_struct.hpp> //phoenix #include <boost/spirit/include/phoenix_core.hpp> #include <boost/spirit/include/phoenix_object.hpp> #include <boost/spirit/include/phoenix_operator.hpp> #include <boost/spirit/include/phoenix_function.hpp> #include <boost/spirit/include/phoenix_stl.hpp> #include <boost/spirit/home/phoenix/object/construct.hpp> namespace mapnik { namespace qi = boost::spirit::qi; namespace standard_wide = boost::spirit::standard_wide; using standard_wide::space_type; struct unicode_impl { template <typename T> struct result { typedef UnicodeString type; }; explicit unicode_impl(mapnik::transcoder const& tr) : tr_(tr) {} UnicodeString operator()(std::string const& str) const { return tr_.transcode(str.c_str()); } mapnik::transcoder const& tr_; }; struct regex_match_impl { template <typename T0, typename T1> struct result { typedef expr_node type; }; explicit regex_match_impl(mapnik::transcoder const& tr) : tr_(tr) {} template <typename T0,typename T1> expr_node operator() (T0 & node, T1 const& pattern) const { #if defined(BOOST_REGEX_HAS_ICU) return regex_match_node(node,tr_.transcode(pattern.c_str())); #else return regex_match_node(node,pattern); #endif } mapnik::transcoder const& tr_; }; struct regex_replace_impl { template <typename T0, typename T1, typename T2> struct result { typedef expr_node type; }; explicit regex_replace_impl(mapnik::transcoder const& tr) : tr_(tr) {} template <typename T0,typename T1,typename T2> expr_node operator() (T0 & node, T1 const& pattern, T2 const& format) const { #if defined(BOOST_REGEX_HAS_ICU) return regex_replace_node(node,tr_.transcode(pattern.c_str()),tr_.transcode(format.c_str())); #else return regex_replace_node(node,pattern,format); #endif } mapnik::transcoder const& tr_; }; template <typename Iterator> struct expression_grammar : qi::grammar<Iterator, expr_node(), space_type> { typedef qi::rule<Iterator, expr_node(), space_type> rule_type; explicit expression_grammar(mapnik::transcoder const& tr) : expression_grammar::base_type(expr), unicode_(unicode_impl(tr)), regex_match_(regex_match_impl(tr)), regex_replace_(regex_replace_impl(tr)) { using boost::phoenix::construct; using qi::_1; using qi::_a; using qi::_b; using qi::_r1; #if BOOST_VERSION > 104200 using qi::no_skip; #else using qi::lexeme; #endif using qi::_val; using qi::lit; using qi::int_; using qi::double_; using standard_wide::char_; expr = logical_expr.alias(); logical_expr = not_expr [_val = _1] >> *( ( ( lit("and") | lit("&&")) >> not_expr [_val && _1] ) | (( lit("or") | lit("||")) >> not_expr [_val || _1]) ) ; not_expr = cond_expr [_val = _1 ] | ((lit("not") | lit('!')) >> cond_expr [ _val = !_1 ]) ; cond_expr = equality_expr [_val = _1] | additive_expr [_val = _1] ; equality_expr = relational_expr [_val = _1] >> *( ( (lit("=") | lit("eq") | lit("is")) >> relational_expr [_val == _1]) | (( lit("!=") | lit("<>") | lit("neq") ) >> relational_expr [_val != _1]) ) ; regex_match_expr = lit(".match") >> lit('(') >> ustring [_val = _1] >> lit(')') ; regex_replace_expr = lit(".replace") >> lit('(') >> ustring [_a = _1] >> lit(',') >> ustring [_b = _1] >> lit(')') [_val = regex_replace_(_r1,_a,_b)] ; relational_expr = additive_expr[_val = _1] >> *( ( (lit("<=") | lit("le") ) >> additive_expr [ _val <= _1 ]) | ( (lit('<') | lit("lt") ) >> additive_expr [ _val < _1 ]) | ( (lit(">=") | lit("ge") ) >> additive_expr [ _val >= _1 ]) | ( (lit('>') | lit("gt") ) >> additive_expr [ _val > _1 ]) ) ; additive_expr = multiplicative_expr [_val = _1] >> * ( '+' >> multiplicative_expr[_val += _1] | '-' >> multiplicative_expr[_val -= _1] ) ; multiplicative_expr = primary_expr [_val = _1] >> *( '*' >> primary_expr [_val *= _1] | '/' >> primary_expr [_val /= _1] | '%' >> primary_expr [_val %= _1] | regex_match_expr[_val = regex_match_(_val, _1)] | regex_replace_expr(_val) [_val = _1] ) ; primary_expr = strict_double [_val = _1] | int_ [_val = _1] | lit("true") [_val = true] | lit("false") [_val = false] | lit("null") [_val = value_null() ] | ustring [_val = unicode_(_1) ] * | attr [_val = construct<attribute>( _1 ) ]* * | '(' >> expr [_val = _1 ] >> ')'* *//These lines got errors!, The first line can be resolved by replace with * * attr [_val = ( _1 ) ], And I can't deal with the second line!* *//Even though, the first line I can't to be sure if the resolve is correct! * ; attr %= '[' >> +(char_ - ']') >> ']'; #if BOOST_VERSION > 104200 ustring %= '\'' >> no_skip[*~char_('\'')] >> '\''; #else ustring %= '\'' >> lexeme[*(char_-'\'')] >> '\''; #endif } qi::real_parser<double, qi::strict_real_policies<double> > strict_double; boost::phoenix::function<unicode_impl> unicode_; boost::phoenix::function<regex_match_impl> regex_match_; boost::phoenix::function<regex_replace_impl> regex_replace_; // rule_type expr; rule_type equality_expr; rule_type cond_expr; rule_type relational_expr; rule_type logical_expr; rule_type additive_expr; rule_type multiplicative_expr; rule_type not_expr; rule_type primary_expr; qi::rule<Iterator, std::string() > regex_match_expr; qi::rule<Iterator, expr_node(expr_node), qi::locals<std::string,std::string>, space_type> regex_replace_expr; qi::rule<Iterator, std::string() , space_type> attr; qi::rule<Iterator, std::string() > ustring; }; } // namespace #endif // MAPNIK_EXPRESSIONS_GRAMMAR_HPP -- 此致礼罗勇刚 Yours sincerely, Yonggang Luo

2 1

[multi_index] Extending multi_index_container hash tables
by Vladimir Voznesensky 16 May '11

16 May '11

Dear Joaquin, Dear all, Please, find the comments below. Joaquin M Lopez Munoz writes: > Vladimir Voznesensky<vvoznesensky<at> gmail.com> writes: > > >> > >> > Hello there. >> > >> > Current implementation of hashed index has, at least, two issues, preventing >> > me from re-using it in some places. >> > >> > First, the time for unlink operation in >> > multi_index/detail/hash_index_node.hpp is O(m) where m is a occupancy of the >> > given bucket. I'ts usually ok for unique index, but seems to hit performance >> > of removing item in a non-unique index. It's all because of using >> > single-linked list instead of double-linked one. >> > The question here is whether non-unique indices will be populated > with many equivalent elements or not: if the former, a singly-linked > list implementation such as that of Boost.MultiIndex certainly > degrades at erasure, but going to a doubly-linked list unncessarily > imposes a non-negligible penalty (one pointer per element) in the > latter case. Having to decide I chose to favor the former case. > I think it should be up to a user to choose: the usage pattern could be very specific (for instance, a LIFO pattern seems to work OK with the single linked machinery). > If you can contribute a Boost-quality modification of the implementation > that lets the user decide between singly-linked and doubly-linked > implementation (say with an extra template paramater in > the hashed<...> index specifier I can certainly add it to the > library. > I have some questions to discuss here. 1. The 1st obvious step is to realize a double- linked list near a single-linked one. I plan not to subclass any stuff from the current detail/hash_index_node.hpp, but use it as a near sample. Should I copy detail/hash_index_node.hpp to, say, detail/hash_index_dbl_node.hpp or use the same file for realization? It seems not to be a problem to add a concrete NodeImpl second template argument to a class bucket_array. 2. hashed_index.hpp arise some gentle problems. I could put another template argument into detail::hashed_index, hashed_unique and hashed_non_unique, but what kind should it be? It's seems possible to add NodeType template argument to class hashed_index without breaking up BOOST_MULTI_INDEX_ENABLE_SAFE_MODE stuff, but how should we pass such sophisticatedly formed type from the final API? detail::hashed_index_args looks like a template hell. So, maybe it would be wiser to just introduce struct hashed_dbl_unique and struct hashed_dbl_non_unique extra variants? > Hahsed indices have the following bucket-handling interface: > > // bucket interface: > > size_type bucket_count()const; > size_type max_bucket_count()const; > size_type bucket_size(size_type n)const; > size_type bucket(const key_type& k)const; > > local_iterator begin(size_type n); > const_local_iterator begin(size_type n)const; > local_iterator end(size_type n); > const_local_iterator end(size_type n)const; > const_local_iterator cbegin(size_type n)const; > const_local_iterator cend(size_type n)const; > > local_iterator local_iterator_to(const value_type& x); > const_local_iterator local_iterator_to(const value_type& x)const; > > (See > http://www.boost.org/libs/multi_index/doc/reference/hash_indices.html#hash_…) > Is this not what you're looking for? > It's not clear from the docs and the sources, how to, say, insert a new element before or after a given one. Thank you.

1 0

Conversion/Enums/Opaque request for interest
by Vicente BOTET 16 May '11

16 May '11

Hi, Lastly I've been working on 3 Boost libraries proposals. * Boost.Conversion (https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/…) * Boost.Enums (https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html) * Boost.Opaque (https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.h…) Boost.Conversion manages with generic explicit conversion between unrelated types. The template function convert_to allows to convert a source type to a target type, using argument dependent lookup (ADL) to select a specialized convert_to function if available. If no specialized convert_to function is available, boost::conversion::convert_to is used. Boost.Enums intends to provide a partial solution to the scoped enums problem ensuring a portable solution compatible with compilers supporting natively scoped enums or not. In addition provides a framework to view enumerations as ordinal types so we can define some specific and efficient enum containers. Boost.Enums is composed of the following parts: * Scoped enums * Ordinal enums * Enum containers * MPL enums * String <-> Enum conversions Boost.Opaque intends to provide a library partial solution to "opaque typedefs". Boost.Opaque provides: * a generic mixin class hierarchy which can be specialized by the user to make new opaque classes. * a generic class hierarchy which can be instantiated by the user to make new opaque typedefs. * a meta-mixin concept that allows to compose in a easy way several aspects of a class in an orthogonal way. * a considerable number of meta-mixins that helps defining new types from an underlying type * Some helper macros that can reduce the declaration of a new opaque type to a single line, emulating the language-based approach. Boost.Opaque and Boost.Enums depend in some degree on Boost.Conversion. These are quite basic libraries that any of you could find useful (or not) and that are not associated to a complex domain, so any of you could have an opinion without spending too much time. Please follow the above links to have a better idea of the motivation of these libraries. Before continuing completing the design, docs and tests of these libraries I would like to know if there is an interest on these libraries and if you have any suggestion on how to improve them, you see something missing or that should be removed. This will help me a lot to concentrate my efforts on the library that reveals more interest. Any comment will really be appreciated. Thanks, Vicente

7 10

Status of make_shared_array
by Joe Dougherty 16 May '11

16 May '11

Hello; Roman Kecher started a thread<http://lists.boost.org/Archives/boost/2009/11/158170.php>in November 2009 regarding the creation of a boost::make_shared_array() function to complement the boost::make_shared()function. What is the status of this addition to the boost library? Thanks Joe

1 0

[Range] Support for array references, svn:executable on headers
by Bryce Lelbach 15 May '11

15 May '11

Boost.Range does not support array reference types. I'd like to add the specializations/overloads/code to Boost.Range to support array reference types (I have commit rights). Neil, is this alright? Does anyone see any see any problems with such changes? (some) of the places where changes are needed: 2011.05.13_18.45.33< VeXocide> it works perfectly fine with char const [5], but not with char const (&)[5] [snip] 2011.05.13_18.47.12< VeXocide> this probably means it's missing a whole bunch of specializations, because the other functions don't seem to support it either [snip] 2011.05.13_18.57.41< wash> VeXocide: where else do you believe changes would need to be made? 2011.05.13_18.58.43< VeXocide> wash, as far as I can tell (I've only checked a few) all functions at http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/co… and http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/co… need to have the specializations added 2011.05.13_18.59.49< VeXocide> an, range_end supports T (&a)[sz] 2011.05.13_18.59.51< VeXocide> ah * 2011.05.13_19.00.12< VeXocide> hmz 2011.05.13_19.01.42< VeXocide> range_difference doesn't 2011.05.13_19.01.53< wash> *nods* 2011.05.13_19.02.30< VeXocide> range_iterator and range_const_iterator don't either 2011.05.13_19.04.12< VeXocide> hmz One test case demonstrating the problem: #include <boost/range.hpp> #include <iostream> #include <typeinfo> int main(void) { std::cout << typeid(boost::range_size<char const (&)[5]>::type).name() << std::endl; return 0; } P.S. A number of the headers in Boost.Range have the svn:excecutable property. Can I remove this property from said headers? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 4

Need second opions from some threading / object creation experts...
by John Maddock 15 May '11

15 May '11

Folks, I'm looking at the code for singleton_pool, and I can't *quite* convince myself that it's completely thread safe and guaranteed to do what it says, the code in question is in boost/pool/detail/singleton.hpp which is a deceptively clever/simple singleton implementation. I haven't been able to break it in practice, but would a sufficiently clever compiler be able to optimize away the call create_object.do_nothing(); and therefore not instantiate the object prior to main()? Thanks in advance, John.

3 5

[phoenix] Creating a download for boostcon
by Daniel James 15 May '11

15 May '11

I'm looking to create the download for boostcon either tonight or tomorrow. I'll probably do it myself rather than using the nightly downloads so that it will include the geometry documentation. Since there were changes to phoenix since the regression test were last run, we need to check that it has been manually tested on all the popular platforms first. I'll run the phoenix (and spirit?) tests on OS X if that will help.

5 12

[Block Pointer] single threaded
by Phil Bouchard 15 May '11

15 May '11

Hi, What if Block Pointer was single threaded for the moment? Would that prevent it from being part of Boost? A lot of applications are single threaded and could take advantage of it already. fast_pool_allocator is not multithread safe as well. The problem is the structure keeping track of each set, block_header, is dynamic (gets created and destroyed over and over) and to maintain a mutex in such conditions is not trivial. Thanks, -Phil

1 0

Mixing different versions of Boost libs in a single process
by Grund, Holger 15 May '11

15 May '11

Hi, I've been looking into how we can improve our own usage of Boost libraries and there's one thing that's been sticking out. We typically have often lots of components running in a single process. Many of these components are developed on different release schedules and while there's certainly demand to adopt later Boost versions, the logistics required to move all of these at the same time is a big headache. Now, while I haven't seen any official word on it, I've always assumed there's no binary compatibility guarantees whatsoever between Boost versions. It's been my impression that there may be a few or even a lot of folks who would be happy to see binary compatibility, but it's unlikely to happen anytime soon. So the next best thing would be the ability to mix different versions of Boost in a single process. Today, linkage names will be identical across versions, which is problematic for static libraries on Windows, and static libs and DSOs on Linux. I remember discussion about making use of GCC's visibility attribute. This would certainly be a step in the right direction. I can't find the page I'm thinking of right now (pointers anyone?). Anyhow, what's the status of this? Also there's BCP, which supports renaming namespaces. That's great, but I guess it could be even better -- e.g. on toolchains where we have inline namespaces or __attribute__((strong)). On Linux targets, symbol versioning via GNU LD version scripts might make things a bit better -- specifically, in that things gone wrong fail earlier and with better diagnostics. Lastly, there's the problem of interop. Say libfoo built with Boost Version 1.40 provides an API like: boost::some_class make_some_object(); If I want to use this in my component where I use Boost Version 1.50, how do I do it? I can think of a few of approaches, none of which really fully convinces me. Consider the same API as a virtual member function, where no linkage name is involved (assuming boost::some_class changed in some relevant way). What to do there? And how to detect this in the first place? There might be other problems like having two different instances of a singleton for two libs in process, or something completely different I haven't thought of. Is there any work going on in this area? Any interest? Thanks! -hg Holger Grund, Vice President Morgan Stanley | MS Strats and Modeling 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

1 0

[ICL] How to define infinite endpoint for the types without infinity?
by Joachim Faulhaber 15 May '11

15 May '11

Hi all, Denis raised a question concerning handling of infinities in icl::intervals in an off list email conversation. I thought this could be of greater interest so I am posting it here. > On Sat, May 14, 2011 at 4:23 PM, Joachim Faulhaber > <afojgo(a)googlemail.com> wrote: > >> 2011/5/14 Denis <denis(a)camfex.cz>: >>> Hello. >>> >>> Boost.Icl has four interval types: closed [a,b] for a<=x<=b, open >>> (a,b) for a<x<b, left-open (a,b] for a<x<=b, rigth-open [a,b) for >>> a<=x<b. >>> >>> That's enough for types which have explicit minimal and maximal >>> values: double, all integers, boost::time_interval, boost::ptime, ... >>> But there are types like string and vector, which have the minimal >>> value (i.e. empty string) but not the maximal one. It makes impossible >>> to define an interval with infinite right endpoint. Intervals (and >>> intervals with infinite right end) have sense for strings end vectors, >>> for sharding. >>> >>> Simplest solution looks like to use tuple<bool, string> in place of >>> string (true means infinity so such a pair will be bigger than any >>> string). But it will force me to use the pair instead of string >>> everywhere in the program (or to create pairs before any interval >>> operation, which implies string copying). >>> >>> Is there a better solution? Maybe to add a 5th and 6th interval types >>> into Icl: closed_to_infinity [a,+inf) and open_to_infinity (a,+inf) ? >>> >>> I asked also here: >>> http://stackoverflow.com/questions/6000655/boost-icl-how-to-define-infinite… >>> >> >> Hi Denis, >> >> thank you for using Boost.Icl. The point that you are addressing is an >> interesting one and I was thinking about the integration of infinities >> while developing the library a few times. Introducing infinity for >> icl::intervals has some problems. We would have to check for the >> infinity condition in almost every function, which makes the code more >> clumsy. >> >> I decided not to do this for pragmatic reasons: In most applications >> of intervals and interval containers infinity is not needed or can be >> replaced by a value that represents some sufficient maximum. So I >> thought that this situation does not justify to bloat the code of the >> interval concept by code related to infinities. >> >> I'd be nice if you could provide a small and compelling example using >> interval containers, where infinities are really needed and can not be >> replaced by some simple pragmatic means. I am always interested in >> those use cases to demonstrate the possibilities and check the limits >> of the usefulness of the ICL. In case you do and the example shows a >> new important use case I will add it to the library's docs and give >> credit to you as the author. >> >> This was the short answer. If this is o.k. for you, I will provide a >> longer answer later this weekend and send it to the boost developers >> and users list and also stack-overflow, because I think the topic is >> of interest to others as well. >> >> Thanks again, >> Joachim >> > > 2011/5/14 Denis <denis(a)camfex.cz>: > Hi Joachim > > Well. > That's all very depend on do we need to add both infinities or only +infinity. > I need intervals with open end for arbitrary byte vectors, but I > cannot imagine what negative infinity can be used for. > Seems like all the types with negative infinity already have an > explicit representation of the minimal value (maybe even signed > biginteger?). a limitless integer implementation can not have a fixed min and max, of course, and whether it has a special value for +/-infinity is up to the library author. To be able to express both infinities might be interesting even for types like built in integers that have their min and max values. > So, hereinafter I talk only about the possibilities of adding +inf as > endpoint of intervals. > And I assume that the domain type has its minimal value. > > I have just made a small patch (about 30 lines) marking +inf in a bit > in `interval_bounds` for dynamic bound intervals. > It has little overhead (the bit is checked only in `bounded_upper()` > `is_empty()` `exclusive_less()` `contains()` `upper_less()` and > `operator <<()`) and enabled only for intervals which are dynamic > bound and continuous. I see that you have tried to keep the impact of the intended infinity-extension of the code small... > As a future optimization, the continuous realm can be divided to > double-like and string-like ones in order to avoid checking this bit > for double-likes. ... and thought even further, which is nice. > Also it not easy to talk about performance when it comes to types like > strings or vectors. > Using something like "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF".... to > represent the maximal blob could be slower and buggy than just an +inf > bit . > > > About the static intervals. > > In the classes `right_open_interval` and `open_interval`, if `_upb` > contains domain's unit value it comes to an empty interval > irregardless what is in `_lwb`. nifty considerations ... > This is not the only way to represent empty interval, any `_lwb` <= > `_upb` would also work. > > So those extra invariants can be used to store infinity without adding > extra fields to the static intervals classes. ... nifty but tricky > Domain's unit in `_upb` can represent +inf, and be seen by comparison > functions as the biggest value, but still the smallest when it is in > `_lwb`. > The case of both `_lwb` and `_upb` having unit will represent the > whole interval so user's tries to construct a empty interval > specifying two units (`open_interval("", "")`) should be corrected in > the constructors (to "\1","\1") > > In order not to impact the performance of the existing > `right_open_interval` and `open_interval`, two new classes > `right_open_interval_with_inf` and `open_interval_with_inf` can be > created by copying with small patching of the comparators and the > constructors. hmm... your posting is interesting with respect to different aspects. You are obviously using icl::intervals (and I guess also icl::interval_containers) with domain types of some types like string and (byte)vector. It was my ambition to allow for such types as domain types in addition to numbers. Of course you have to watch efficiency, if your values get large (not to mention approaching infinity ;) Because you are using icl in this realm you might experience difficulties and even detect bugs that no one else has found. Also you might explore properties of the underlying concept, which is the concept of a sequence, I guess. As I wrote in my first answer, I'd be very much interested in a short compelling example for the tutorial that demonstrates the kind of use case that you cover. It might be kind of unique and open up a new horizon of icl usage. I think it is a good idea to implement infinity as a property of intervals instead of using special values. I had similar considerations, but as I mentioned earlier, I didn't do that for pragmatic considerations. I think a real need to work with infinities does not occur in most applications. And even if someone want's to use them, it is always only a phenomenom that applies to the very first or last interval of an interval container. It might be true that by good design and use of metaprogramming we might be able to limit the impact a infinity extension to just a few functions and I acknowledge you tried to demonstrate that. Still these are functions (e.g. exclusive_less) that are called extremely frequently. So there is performance penalty also on those majority of instances where infinities are not needed at all. I appreciate your ideas but I guess I need some more time to think about them. One possibility might be to create a concept for infinity bounded intervals on top of dynamic intervals. So only users who explicitly need to model infinity bounded intervals would choose those. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Boost.Context review result
by Vicente BOTET 15 May '11

15 May '11

Hi, this was my first experience as review manager and it has been more difficult than I had expected. Apologies if I forget some important things or I misunderstood others. I hope that the major points have been taken in account. Here it is the result of the Boost.Context review. The library is accepted provisionally and will need to address some mandatory points before a mini review (4/5 days). There were not too much complete reviews (5) but globally all the reviewers voted for acceptation and two subject to some major redesign modifications. I hope I didn't miss somebody. YES Gordon Woodhull YES/Cnd Giovanni Piero Deretta YES Artyom YES Nat Linden YES Phil Endecott YES/Cnd, Jeffrey Lee Hellrung, Jr Thanks to all the review participants Gordon Woodhull, Giovanni Piero Deretta , Artyom, Nat Linden, Holger Grund, Phil Endecott, Jeffrey Lee Hellrung, Jr.. Special thanks to Giovanni Piero Deretta showing some major flaws in the global design and Holger Grund for showing a (possible) major bug on the Windows implementation. I know Oliver that you have already redesigned your library, but if there are points that you have not been addressed yet or have some difficulties addressing them, I will suggest you to work closely with Giovanni, he know well the domain and have a lot of good ideas, and exchange on this ML. You should follow up more closely the discussions during the mini review and even try to get feedback from the ML posting how you see your redesigned library. Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local). Vicente Review Manager

5 8

Phoenix: error: extra ‘;’ on boost/phoenix/core/environment.hpp
by Vicente BOTET 15 May '11

15 May '11

Hi, There is an error on In file included from ../../../boost/phoenix/core/call.hpp:12, from ../../../boost/conversion/fp/convert_to.hpp:15, from builtins.cpp:16: ../../../boost/phoenix/core/environment.hpp:446: error: extra ‘;’ It seems that the error: extra ‘;’ are on lines 433 and 444 at the end of two functions definitions. Could this be fixed? Thanks, Vicente

5 6

[countertree] New Version
by Francisco José Tapia 15 May '11

15 May '11

Hi this message is to announce the new version of the countertree library. You can find the zip file with the code and the documentation in < http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…> or if you want a quick look , you can see in my web page < http://fjtapia.webs.com/works/countertree/index.html> Technically this library is an implementation of a binary red-black counter tree. Colloquially is a balanced tree with an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container. If the information stored is unordered, we have the class boost::vectortree. This class have the same interface than a std::vector. The std::vector is very fast O(k) inserting and deleting at end , but very slow O(N) if you must do in other positions . In the vectortree all the operations are O(logN). It is a bite slower than std:vector inserting and deleting at end, but much more faster for to insert and delete in any other position. If the information stored is ordered, you have the classes boost::set, boost::multiset boost::map and boost::multimap. These classes have identical interfaz than the std::set , std::multiset, std::map and std::multimap, and additionally, access by position with the function at(pos). The iterators are random access and have a function pos() which return their position in the container. You can mix safely access by iterators and access by position. The performance of these classes are similar to the classes of the STL. #include <boost/countertree/set.hpp> #include <iostream> int main ( void ) { //------------------------ begin -------------------- boost::set<int> A ; for ( int i = 0 ; i< 100 ; ++i) A.insert(i); for ( int i = 0 ; i < A.size() ; ++i) std::cout<<A.at(i); return 0 ; }; For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions . You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC (32 and 64) and Visual Studio 2008 (32) and Visual Studio 1010 (32 and 64). Please, if you find any problem, please mail me ( <fjtapia(a)gmail.com>) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. Francisco Tapia <fjtapia(a)gmail.com>

7 12

Phoenix: is there a Phoenix expression trait?
by Vicente BOTET 15 May '11

15 May '11

Hi, I'm adding a convert_to Phoenix like functor to Boost.Conversion. I would like to use the same name, i.e. convert_to, but the overloads conflict. I would like to use sfinae to choose the correct overloading between template inline typename expression::convert_to, U>::type const convert_to(U const& u); template Target convert_to(Source const& from, boost::dummy::base_tag const& p=boost::dummy::base_tag()) Is there a trait that can be used to detect if the parameter is a Phoenix expression? BTW, I have just based my implementation on the one for static_cast, that uses the detail boost::phoenix::detail::target Could someone explain me why this is needed? Could this detail be moved to the user interface? Best, Vicente

3 2

[context] new version (stack unwinding, ASIO example, ...)
by Oliver Kowalke 14 May '11

14 May '11

Hello, I've reworked on boost.context regarding to the suggestion of the last review (thanks to Vicente as review manager) - but not all requests could be fulfilled. The new lib supports stack unwinding, has examples like C# enumerator concept (yield_return(), yield_break()) and an adapted version of a echo server using stack-less coroutines written by Chr. Kohlhoff and Java continuations. The new version (boost.context-0.7.0.zip) is published on boost vault and the documentation can be read here : http://ok73.ok.funpic.de/boost/libs/context/doc/html/ . Best regards, Oliver

1 0

[BGL] container_gen (was Re: [tree] reviving the tree library)
by Cromwell Enage 14 May '11

14 May '11

--- On Fri, 5/6/11, Erik Erlandson wrote: > My storage models are effectively wrappers around the > underlying containers (the container is a member of > the node type). I originally thought it would be nice > to allow a user to somehow drop in any container they > wanted, but I was unable to find a way to make that > work properly. [snip] > Perhaps container_gen would allow it to be more fully > automated. The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter. One current limitation that may be important to you is the inability to supply custom allocators as well. I saw in the sandbox that the BGL authors were planning to provide selector templates parameterized by allocator type. I'm wondering how that work is progressing. At any rate, to the BGL authors: I find container_gen to be a useful utility metafunction outside its current home. Would anyone else like to see it become a first-class Boost citizen? Cromwell D. Enage

3 5

[signals2] trunk - vc++ 10 warning about assignment operator
by Edward Diener 13 May '11

13 May '11

An attempt to instantiate a signals2 signal of the form: template <class T> class notification_boost_signal2 { public: boost::signals2::signal<void (const i_some_interface<T> &,boost::optional<T>,T)> sig; }; for notification_boost_signal2<char>, gives the error message in vc++ of: "C:\Programming\VersionControl\boost\boost/signals2/detail/signal_template.hpp(367) : warning C4512: 'boost::signals2::detail::signal3_impl<R,T1,T2,T3,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>::slot_invoker' : assignment operator could not be generated" There is a huge template trace leading up to this final warning, but before giving it I wonder if anyone knows what it is about ? Perhaps Frank Mori Hess or Douglas Gregor is out there and can tell me what is happening.

3 4

[Block Pointer] multithread help
by Phil Bouchard 13 May '11

13 May '11

Hi everybody, I was wondering if there is anybody familiar enough with Block Pointer that could give me a hand regarding multithread support. Once again the test file is at: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… The main class I am trying to protect with a mutex is block_header from: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp Thanks, -Phil

3 7

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 13 May '11

13 May '11

(This email has earlier been sent to the wrong list. Thanks to Steven Watanabe for pointing that out.) Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

5 11

boost lib must provide C interface?!
by Oliver Kowalke 13 May '11

13 May '11

Hi, can a boost C++ library be required/forced to provide a C API? Even if the library author doesn't like this idea - because he would be responsible for C stuff. <boost/config.hpp> include <cstddef> which will not be available for a C compiler - maybe this is an indication that boost libs are not required to implement a C-API. regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

5 6

Testing Problems
by Christopher Jefferson 13 May '11

13 May '11

Apologises, the following message is going to be a fairly long list of complaints. However, I wanted to post them rather than just let them disappear. Some background: I previously worked on getting clang and libc++ working in boost, in both c++03 and c++0x mode, submitting a large number of patches to achieve that goal. I also ran regression testers for this libraries. I am broadly planning on giving that up, unless various things improve in various ways. That isn't a threat, just I don't have the man and CPU time to spare working around issues in boost. Problems: 1) Running the boost regression tests takes unacceptably long. I would like to run tests for clang with and without libc++, with and without c++0x mode. Running those 4 sets of tests takes a huge amount of time. Various tests (and I keep meaning to try to find which ones) take huge amounts of memory, meaning it isn't reasonable to run even a single-threaded boost regression test in the background on a 4GB machine. Running tests in parallel doesn't seem to speed them up particularly, while bringing the machine even more onto it's knees. 2) The boost regression testpage ( http://www.boost.org/development/tests/trunk/developer/summary.html ) is fairly useless, as it doesn't say when a particular test failed. This means I just have to try to memorise the current state of all the compilers I am interested in, and look for new fails by eyeball. Much more useful would be changing the 'fail' to the most recent svn version at which a new fail occurred? 3) I always find trac hard to use. I usually want to do 2 things: a) Find all open bugs attached to package X b) List all bugs which I filed, or have have submitted a message to. I find both of these easy to achieve with bugzilla, and not with trac. 4) Getting patches, in particular very simple ones (like warning suppression) can take multiple prods and can languish for a long time in trac. I'm not sure what the best solutions to all of these problems are. Obviously they could each be tackled but several of them would involve changes to many different boost libraries, which is something I find can be like pulling teeth (some maintainers are extremely good, I certainly don't want to tar everyone with one brush!) On practical note, is it time for boost to move to officially supported compilers for each release? These could easily be read off the testing page (no test = not offically supported), and the packages which do not pass testing could be briefly listed in the release notes. This might have the advantage of encouraging more people to run tests, if they want their compiler to be offically supported. Apologises for the lengthy rant, Chris Jefferson

2 1

[review] string convert
by Gordon Woodhull 12 May '11

12 May '11

Hi Vladimir, Ed, all, It is a curiosity of Boost reviews that a vote of conditional acceptance is actually more powerful than a No vote, because if you vote No, the author might try to convince you to change your vote but otherwise has no incentive to listen to you any further. Therefore I vote to accept this library with the strong condition that a simpler syntax be adopted, doing away with the odd static ::from() function, and completely getting rid of the confusing, error-prone lazy functions. I am aware that the author thinks the present syntax is necessary, but I will argue against it in each case. (As another meta-review comment, I've noticed a few authors saying they won't consider any changes unless their library is accepted. This sets up a deadlock situation: the reviewer will not accept the library without the changes, and the author won't make the changes without acceptance. Everyone digs in their heels and nothing gets done. I think any author who really wants their library to be in Boost should be willing to submit it for a second review. And I think reviewers should tend toward conditions on acceptance rather than no votes. My two cents.) > - What is your evaluation of the design? That's the focus of my review, specifically, the design of the interface. Supplying a default value, a don't-throw option, and applying manipulators/locale, are the major features missing from lexical_cast. So I think there is no doubt that a library like this is needed, if lexical_cast can't be upgraded. And according to its author, lexical_cast can't be upgraded because it must look like a cast and all these features require more parameters (template or actual). So, fine, let's have a replacement that's not .*_cast. It is incredibly clear what lexical_cast does because it uses the standard meaning of the operators, function calls, and return values. There is a lot of value in that. I don't think it's always a bad idea to have lazily evaluated objects or creative uses of operators, but IMHO if it is possible to do something more clearly with the standard order of evaluation and standard use of operators and function calls, then that should be preferred. The interface of the proposed Convert library is not simple enough. To start out with the most annoying thing, I don't like "::from" at all. The replacement should look as close to lexical_cast as possible. So, why the extra '::from'? Even though I disagree with the lazy evaluation (see below), even that doesn't seem to require this weird static member syntax. Is '::from' just so that '::result' will not feel lonely? For the rest of this review, I'm going to refer to convert<T>::from(s), but please keep in mind that I really think it should be something like string_convert<T>(s). So, next '::result'. It's some form of optional return. So why not just return optional? It is not much less to type convert<int>::result maybe = convert<int>::from("not an int"); versus optional<int> maybe = convert_cast<int, use_opt>("not an int"); (Where use_opt might also be spelled dont_throw, opt_out, .. I don't really care. Yes there may be problems because of the necessary deduced template argument for the source type. But isn't there a way around that with Boost.Parameter?) Why should the LHS modify the behavior of the proxy object returned by ::from? It's far too much to think about for such a simple operation. I'd rather the function clearly did or didn't throw on its own, not be influenced by its context. Lazy evaluation in expression templates is typically used to offer some kind of declarative syntax. So let's ask ourselves if that is needed here. The main innovation here is a lazily evaluated object which can then - throw or not throw based on its context convert<int>::result i = convert<int>::from("not a string"); - take iostream manipulators, which are applied before the conversion takes place. - take additional options through a second application of function call operator (!) All of these uses defy the way we ordinarily read function evaluation. What, the conversion is now feeding some data into std::hex? And then where does it go after that? It gets returned? Weird. The right shift operator was chosen in the standard because it depicts an arrow; otherwise there is nothing that says I/O about it. Thus the only way this syntax would make sense to me is if it were int i = std::hex >> convert<int>::from("deadbeef"); and then unfortunately it would be impossible to have more than one manipulator without some horrible parentheses, because of the left associativity. I don't like the look of streaming operators that lead nowhere. No, why not just int i = convert<int>::from(s, std::hex); ? Or from(s, _manip = std::hex) Or, at worst (and I don't see why this is necessary) from(s)(_manip = std__hex); If you want the operator syntax, just do int i; stringstream(s) >> std::hex >> i; If it's really got to be one line, a syntax like int i = stringstream_(s) >> std::hex >> ret_; would at least make sense and I'm sure that there's a way to do that almost as succinctly using Phoenix. On a similar nice-feature-but-weird-syntax note, let's look at the Using Boost.Convert with Standard Algorithms section, which offers a few ways that you can use convert<T>::from() to create a functor: std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from(string(), -1) >> std::hex); std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from<string>()(fallback_ = -1) >> std::hex); Apparently if you pass an empty string or omit the parameter to from(), it creates a function object which takes a string as a parameter. Is this correct? This seems like it would have unwanted consequences, since we now have a function object that can take either extra options or the string input. Again, I'm not against clever syntax, but this seems promiscuous and confusing. I think it would be much more appropriate to provide a Phoenix function object for the purpose, something like std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert_<int>(_1, -1, std::hex)); Sigh of relief. I see what that means immediately, and it doesn't make me worry about what convert's going to do if I forget a parameter. I agree with Jeroen's request for a default-constructed version. I don't see why no syntactic sugar could be doled out for this, a _defcon (template or real) parameter or whatever. I also want to mention type-to-type conversion, which Vicente Botet has thought out much more thoroughly in his Conversion library. This library offers type-to-type conversion seemingly as an afterthought, just because the syntax allows it. I definitely see the value of a conversion mechanism that first looks for a direct type-to-type conversion and then defaults to using type-to-string-to-type. I just don't think conversion should always do that, and I don't think such a mechanism should be called plain convert. It does make any more sense to call such a thing plain convert than it does to start optimizing lexical_cast with special cases that don't use strings (sorry!). It would be called best_conversion or something that conveys that it's doing the best it can based on what converters have been "installed" at compile time. Again my objection is not to the functionality but to an obfuscating interface where you're not sure what behavior you're going to get. I feel the same about the string-to-string conversion: it seems to be in there just because the syntax supports it, not because it actually makes sense here. I guess this is because library is called Convert instead of String Convert or Via Stream Convert, which is its main focus (and rightly so). Apologies for repeating this: I still don't get why the extra options go into a second function call operator. I found some earlier messages where you simply added those to the first function call. Simplify, simplify, simplify the interface. Please. To summarize, I don't get why we can't just have this simple clear syntax: optional<int> i = string_convert<int, dont_throw>(s); // or string_convert<int>(s, _throw=false) if that's impossible int i = string_convert<int>(s, manip_ = std::hex); It's (plain) functional. There's no question when things get evaluated or thrown. I don't care about any of the particular names used, just the syntax. > - What is your evaluation of the implementation? I read the code enough to answer my own questions about what the library actually does. As noted, I disagree with many design choices, but the implementation seems fine. The only thing that caught my eye as a little strange is that there's the string_sfinae namespace and header which in fact contains a bunch of metafunctions which are sometimes used in sfinae and sometimes just used as metafunctions. Obviously not a big deal, just some metonymy or historical artifact there. To return to convert<>::result On Apr 27, 2011, at 7:07 PM, Vladimir Batov wrote: > They, indeed, seem to provide *similar* functionality. In fact, convert::result *uses* boost::optional. If you have a look at convert::result (it's quite small), then everything else in addition to boost::optional is what convert::result adds. In words, IMHO convert::result is better than boost::optional tailored for its domain (conversions). So you made me look. I conclude that the only functionality it adds is the ability to delay throwing on error until the result::value() is called, am I wrong? I don't understand why you'd want this, because I thought the whole point of using ::result was when you didn't want to throw. But maybe I'm missing something. Again I think this could all be SO much simpler. > - What is your evaluation of the documentation? It's well written and explains the subject well. It seems a bit flippant in places ("I've included this and that because why not?" kinds of statements) and IMO that's because the focus of this library is a little too fuzzy. Stick to string/stream conversion, fix the problems with lexical cast. Don't try to build a general conversion framework unless you're really willing to think that through. I looked for a Rationale section that would explain why this functionality could not be included in lexical_cast, and could not find it. Vladimir, I know you said On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I again urge you to please dig the archives to see why that "extra > functionality should be added to boost::lexical_cast" view is not exactly original and most importantly why it was decided *not* to proceed as you insist. But I don't think that's a substitute for explaining to new users why they can't get what they want with modest improvements on the lexical_cast interface. Why is it that they really want some fancy lazy function object / "declarative" interface? Likewise with this non-argument: On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I've come to a firm conclusion that that additional > functionality/configurability is *not* implementable within the boundaries of the lexical_cast interface. In particular, the TypeIn and TypeOut types must be discriminated, i.e. one type has to be specialized first. Without going into details I'll just say that otherwise is just does not work. So, it has to be convert<TypeOut>::from<TypeIn>. You can take my word for it or you could walk that road yourself. Sorry, but I find this response either lazy or rude. You wrote the library: you explain to us why the way it is! I'd really like to know why you think it's necessary to do convert<T>::from(s) rather than the much more familiar and easy-to-grasp string_convert<T>(s). I don't want to try to write it myself to find out why it does or doesn't need to be that way. You entered a fairly contentious arena with a majorly different interface. Write a rationale and don't just tell us to search the list. > - What is your evaluation of the potential usefulness of the > library? Very, very useful. I use lexical_cast and am frustrated by the limitations. > - Did you try to use the library? With what compiler? Did you > have any problems? No, I did not - I see how it works and trust that it does. I was not tempted to start looking for ways to make the library produce surprising results because it was immediately clear to me from the interface design that those misbehaviors would exist. I'm not always a Keep It Simple person, but in this case, please do. Otherwise you're destroying one of the best features of lexical_cast. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I spent about 5 hours reading the documentation and code, and 5 hours reading/rereading the current reviews and writing mine. I wish I'd had time to go back to the earlier discussions, although I searched a little bit; again I think everything that could be learned there should have been in the Rationale. > - Are you knowledgeable about the problem domain? Moderately. I like to know how every construct I'm using works, and I gulp at the inefficiency of lexical_cast every time I use it, even though I never use it where efficiency matters. To further prove my point that conditional acceptance is stronger than voting no, note that I've basically made my yes vote conditional on fixing most of the things Thomas Heller complained about, notably On Apr 26, 2011, at 2:58 PM, Thomas Heller wrote: > Moreover, I don't get how the design really is superior to boost::lexical_cast, and why it couldn't been implemented as an extension to that library. (It can't take a .*_cast name, but it can use the simple syntax.) > The use of this converter function object looks like a nice concept at first sight but, as mentioned above, in the end, probably adds more confusion and problems than anything else. (It confused me and didn't look nice.) > I don't think that having everything hidden behind this static from function is wise and should be rethought. Different functions, for different purposes would be better suited. On Apr 27, 2011, at 5:14 AM, Thomas Heller wrote: > Even though you tried to be minimal and > simplistic, the function is overloaded with too different (in concept) > behavior that its really confusing to get what the function is really > doing. So my end result is that its not really minimal and > minimalistic, but bloated ... sometimes, more is less. (I think more template or function parameters could also do the trick.) I realize that my conditions mean some serious redesign, but this is an 834-line library and it would probably be even shorter without all the unnecessary lazy functions and weird out-of-place operators. I want to contrast this with my No vote in the XInt review, where I also had issues with the design. I would have voted for conditional acceptance of XInt if it were possible, but the changes there seemed like they would need additional review. String Convert is much simpler and I think that a compromise could be reached to (IMO) simplify the interface and answer most of the objections that Thomas, Jeroen, and I have made. I apologize to Ed for making a complicated vote. I'd be glad to clarify my position if needed. Cheers to Vladimir - you've identified an important problem! Now just give it a clear interface and we'll have something good. Gordon

13 163

[local] Help for the Alternatives section
by Lorenzo Caminiti 12 May '11

12 May '11

Hello all, I am updating Boost.Local docs and I could use a some help in getting the Alternatives section right http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… . How can I program the following code (its local function and `factor` constant binding) using Boost.Phoenix, Boost.Lambda, and C++0x lambda functions? If you know, can you please reply with the actual code? #include <boost/local/function.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, // Variable `factor` bound as constant. bind& sum, const bind& factor) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; // Local function `add` passed as template parameter. std::for_each(v.begin(), v.end(), add); return 0; } Thank you very much! -- Lorenzo

14 82

Delimiting protocol messages (was [asio] read_some() splits data)
by Marsh Ray 12 May '11

12 May '11

On 05/11/2011 09:36 AM, Andrew Holden wrote: > On Wednesday, May 11, 2011 9:57 AM, Slav wrote: >> Then messages of length not multiple of 128 (BUFFER_SIZE) >> will not be read - tested it, anyway, after >> last socket::read_some() (with readBytes> 0&& < >> BUFFER_SIZE) next socket::read_some() never ends. > > It would probably help to understand that TCP has no concept of a > "message". Anything you write to a socket is appended to a stream of > *bytes*. Alternatively, we could say that TCP, in fact, does have a well-defined concept of messages: they are all exactly one byte long. > Several subsystems on both the sending and receiving computers ... and sometimes boxes in the middle ... > will have the option of splitting and combining adjacent buffers with no > consideration to how big each individual write was. I've done a little protocol stuff with ASIO now and I must say it's a lot of fun and I can't go back to doing it any other way. > On further thought, I think I see the problem (and I apologize for the > bad recommendation in my last email). Your sender somehow needs to > communicate the message size or flag the end of the message. A partial > list of options includes: The pattern I encounter over and over again (often at multiple levels in a protocol) is: class protocol_layer_context { vector<uint8> buffer; void on_received_data(vector<uint8> & rx_bytes) { buffer.append(rx_bytes); // perhaps a virtual override. size_t msg_len = this->parse_len_from_start_of_buffer(); if (buffer.size() <= msg_len) { vector<uint8> msg_buf = consume_data_from_front_of_buffer(buffer, msg_len); // perhaps a virtual override this->process_complete_message(msg_buf); } // post another ASIO read request this->request_more_data(); } ... But there are some important issues with this naive pseudocode: 1. It can result in recopying the data a bunch of times for every protocol layer, killing performance. 2. It's susceptible to a denial-of-service (DoS). Bad guy can send trick you into allocating all your memory. 3. Sometimes the length of a message is stated at the beginning of the message, sometimes it isn't known until the end. 4. No processing happens on the message until it's completely read, but some protocols really need the receiving endpoint to process it incrementally. 5. Error handling 6. Optimal threading 7. Etc. We find bugs in exactly this logic all the darn time. Often the data being received is untrusted and possibly malicious. Real-world protocol implementations will commonly crash under fragmentation fuzzing, sometimes resulting in exploitable security holes. In a sense, this is the general refactoring problem of 'incrementalizing' a parsing function by moving all its state from stack variables into a longer-lived context object. We've seen it done successfully with coroutines, but that's not a commonly accepted solution because, frankly, the native C/C++ runtimes have not yet given coroutines the love (i.e., portability and performance guarantees) they really deserved. If someone figured out how to leverage generic techniques to handle just the unidirectional message delimiting problem in a bulletproof way I think it would make a really great boost library. - Marsh

1 0

Free BoostCon Registration
by Dave Abrahams 12 May '11

12 May '11

Unfortunately, two of our registrants had to cancel after the refund deadline. Fortunately, they have offered their registrations to anyone who might have not registered because of the cost. If you would like to claim these available registrations, please send email to our registrar, Marshall Clow (mclow AT gmail.com) Thanks, and see you in Aspen! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 1

[spirit][qi] Dynamically combine Boost.Spirit.Qi rules at runtime
by Daniel F. 11 May '11

11 May '11

Hi, I recently tried to combine an arbitrary number of rules as alternatives in Boost.Spirit.Qi. Since rules are implemented as objects it seemed feasible to me. My motivation was to make certain parts of my grammar easily extensible. Unfortunately, I ran into some problems, so I wrote a simple program (see attachment for the complete code) demonstrating the unexpected behavior. Here's the key part: // "Dynamic" version - Does not compile! :( /* std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); rule_t grammar; grammar = (*i)(qi::_r1); //[no_op] for(++i; i!=last; ++i) { grammar = grammar.copy() | (*i)(qi::_r1); //[no_op] } */ // "Dynamic" version - Kind of works! :-/ std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); qi::rule<iterator_t, int()> temp; temp = (*i)(qi::_val); //[no_op] for(++i; i!=last; ++i) { temp = temp.copy() | (*i)(qi::_val); //[no_op] } rule_t grammar; grammar = temp[qi::_r1 = qi::_1]; Now, I suppose that the first version (commented out) doesn't compile, because I'm not passing the inherited attribute down to grammar.copy(). I would love to know if there's a better way of doing this than the workaround that is the second version. The second version actually compiles and it seems to do the right thing. However, once I attach a simple semantic action as indicated in the code using comments (see "[no_op]"), the behavior becomes really weird. Rather than printing 0,1,2 as before, the program prints 0,0,2. So I'm wondering, is what I'm trying to accomplish resulting in undefined behavior? Is this a bug? Or, quite possibly, am I just using something (e.g. semantic actions?) the wrong way? Thanks for reading, Daniel

4 7

[convert] no-throw and fallback feature
by Vicente BOTET 11 May '11

11 May '11

Hi, I was thinking on the fallback feature a little bit more and I've the impression that we can get it for free. If we accept that we need a no-throw function such as try_convert_to that returns an optional Target we can have the fallback using the optional::get_value_or function auto r = try_convert_to(*int*)(s); int i = r.get_value_or(fallback); or just int i = try_convert_to(*int*)(s).get_value_or(fallback); or int i = get_value_or(try_convert_to(*int*)(s), fallback); I don't know if it is worth adding a function that does all in one int i = convert_to_or(*int*)(s, fallback); Best, Vicente

5 25

[autoindex] Review
by Edward Diener 11 May '11

11 May '11

This is my review of autoindex. - What is your evaluation of the design? Very clean and easy to understand. - What is your evaluation of the implementation? Did not look at the internals. - What is your evaluation of the documentation? Generally good. Here is a list of mostly grammatical errors: 1) Overview: "the HTML indexes look a lot less good" -> "the HTML indexes look a lot worse" Step 1: Build the AutoIndex tool: "Finally note that tools/auto_index/auto-index.jam gets copied into the same directory as the rest of the Boost.Build tools." -> I am not sure if this means that building AutoIndex does this automatically or the end-user must do it but the sentence grammar suggests the former, which does not happen for me. If the end-user should do it, the line should read "Finally note that tools/auto_index/auto-index.jam should be copied into the same directory as the rest of the Boost.Build tools." 2) Step 2: Configure Boost.Build jamfile to use AutoIndex "Always send the output to a log file. It will contain of lot of stuff, but is invaluable to check if all has gone right, and else diagnose what has gone wrong. -> ..."and also diagnose what has gone wrong." ..."or else diagnose what has gone wrong." 3) Available Indexing Options: For Document Type 'library', Available Index Types says 'See Chapter'. I am guessing this means it is the same as Document Type 'chapter' but it should be made clearer in the remark. 4) Step 7: Iterate - to refine your index: "You can restrict which sections are indexed for a particular term. So assuming that the docbook document has the usual hierarchical names for section ID's hierarchical names for section IDs(as Quickbook generates, for example), you can easily place a constraint on which sections are examined for a particular term. " ' -> remove the second repeated "hierarchical names for section IDs". "This would avoid an index entry every time ° kelvin is found, something the user is unlikely to find helpful. " -> "This would avoid an index entry every time 'Kelvin' is found, something the user is unlikely to find helpful. " 5) Script File (.idx) Reference: "Blank lines consisting of only whitespace are ignored, so are lines that start with a #. (But, of course, you can't append # comments onto the end of a line!). " -> I am guessing this should be: "...(But, of course, you can append # comments onto the end of a line!)." "recurse An optional boolean value - either "true" or "false" - that indicates whether to recurse into subdirectories. This defaults to "false" -> Needs a period at the end. "type The type to which items found using this rule will assigned, index terms created from the source file and then found in the XML, will have the type attribute set to this value, and may then appear in a specialized index with the same type attribute " -> Needs a period at the end. The only other issue in the documentation is that while there is very good documentation about what type of XML container wraps an internally generated index, I am not sure what this actually means to a Quickbook author. No doubt somewhere there is probably a discussion in Docbook of what these XML containers mean and do but, aside from experimentation, the user of AutoIndex is not likely to understand what it means to put the Index in a specific XML container and how this affects the final layout of the documentation. Perhaps some further explanation of what this actually means for an AutoIndex user, especially for a Quickbook document, would be appropriate. - What is your evaluation of the potential usefulness of AutoIndex? Immense. Searching through documentation of even mildly complex libraries which have little or no index is very frustrating. - Did you try to use it? With what compiler? Did you have any problems? I have used it for the documentation of my VMD and TTI libraries with both gcc and vc++ under Windows. Any problems were of my own making and the author of AutoIndex answered my questions when I was stuck. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A pretty deep study, although I have not tried to add anything to the index file other than 'scan' statements. - Are you knowledgeable about the problem domain? Yes. I vote for the library to be accepted into Boost. Edward Diener

2 1

inquiry about proposing a new Boost library for a tree template container class
by Erik Erlandson 11 May '11

11 May '11

Hello, I recently completed an STL-compliant template container class for storing data in an arbitrary tree structure. It seemed like it might be a useful component of Boost, and I wanted to ask about how new projects are submitted for consideration. The current incarnation of the project is called 'st_tree', and resides here: https://github.com/erikerlandson/st_tree/wiki Regards, Erik Erlandson

7 27

[type_factory] new utility/class proposal
by Vlad Lazarenko 11 May '11

11 May '11

Dear Boost developers, How many times in your experience you needed to associate a type with some identifier known at run-time only? It’s like having an associative container with numeric key and type as a value. Not object, but type. This is a concept similar to object factory pattern but with no objects, only their types. I call it a type factory. There might be a solution for this in Boost already but I haven’t seen it. Please forgive me if I am just being blind. Just to give you a little taste of what I mean – imagine that you have a stream of bytes where objects of different types and sizes are stored (serialized), and one byte identifying a type is preceding every such serialized object, and you need to parse it. One approach is to have a switch statement, for example, where all type identifiers are cased, and parse data depending on a type. But then, as list of types grows and/or shrinks, maintenance of this switch becomes unpleasant. And if this logic is in some base library, where user specifies list of types, it becomes even worse. There might be another way, I thought, and came up with sort of hybrid between compile-time types and run-time identifiers – a type factory. I am wondering if anyone else will find it useful. Perhaps we can have it as part of boost utility classes. Here is a very simple example of usage: https://github.com/Yocto/type_factory/blob/master/test/simple_example.cpp It gets a number from “argc”, and then, depending on its value, invokes “speak” method of either “cow”, “dog” or “alligator” classes. More functionality is covered in unit test. Basically, the type factory, given a list of types as “MPL vector“ is enumerating them from 0 to N. Later, for any given instantiation of “create” method, it generates a dispatch table for invoking of one of template methods (with no arguments) on a supplied “visitor” class. The source code of the class is here - https://github.com/Yocto/type_factory/blob/master/include/yocto/type_factor…. There are a lot of details, but the main class exposed to the user-land API is “type_factory”. Please let me know if you are interested in such a concept. Thank you, Vlad

2 1

Review manager needed for TTI library
by Edward Diener 10 May '11

10 May '11

I am looking for a review manager for my TTI library in the review queue. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. Since I have acted as a review manager for another library, and have expressed my willingness to do so for some other libraries, I would appreciate it if someone, who understands Boost MPL well and the compile-time introspection problems my library solves, would be a review manager for my own library.

3 6

Re: [boost] [trolling] Alexander's crusade (was: [provocative] Whom did the SFC pay to list boostdevelopers as a whole in "Current Member Projects"?)
by Matt Chambers 10 May '11

10 May '11

> ... pointless quoted legal jargon... What's your point? -Matt

10 17

[container_bptree] first version of submitted library
by Vadim Stadnik 09 May '11

09 May '11

Hi all, The first version of submitted library container_bptree http://www.boostpro.com/vault/index.php?action=downloadfile&filename=contai… offers a number of STL variants of containers based on B+ trees. These powerful data structures enable the implementation of various useful extensions of STL containers and iterators. One of the most interesting improvements is the efficient algorithm accumulate(), which has computational cost *O(log N)* in the worst case. This algorithm can increase performance of solutions in numerous application areas, including traveling salesman problem. Please read the documentation and try the included test code. The current implementation has been developed for Visual Studio compilers (2008 and 2010). Portability of this library has not yet been tested. I would really appreciate if someone could compile and run the test code using other compilers and let me know if there are any technical issues. Any suggestions concerning improvements of the current version of this library will be carefully analyzed and implemented if possible. The potential of B+ trees has not yet been used to its full capacity. There are a number of options for further extensions of this library. The community interest and feedback will have an effect on the priority of the development of new features and efficient algorithms in future versions of this library. Thank you, Vadim Stadnik

2 2

[phoenix] not playing nice with other libs
by Eric Niebler 09 May '11

09 May '11

The following trivial program fails to compile: #include <boost/phoenix/core/limits.hpp> #include <boost/numeric/conversion/converter.hpp> It generates the following: In file included from ../../../../branches/release/boost/numeric/conversion/detail/is_subranged.hpp:17, from ../../../../branches/release/boost/numeric/conversion/detail/conversion_traits.hpp:21, from ../../../../branches/release/boost/numeric/conversion/conversion_traits.hpp:13, from ../../../../branches/release/boost/numeric/conversion/converter.hpp:13, from main.cpp:2: ../../../../branches/release/boost/mpl/multiplies.hpp:38: error: wrong number of template arguments (12, should be 5) ../../../../branches/release/boost/mpl/aux_/preprocessed/gcc/times.hpp:68: error: provided for ‘temp late<class N1, class N2, class N3, class N4, class N5> struct boost::mpl::times’ Phoenix is changing the following fundamental constants: BOOST_PROTO_MAX_ARITY BOOST_MPL_LIMIT_METAFUNCTION_ARITY BOOST_PROTO_MAX_LOGICAL_ARITY BOOST_RESULT_OF_NUM_ARGS IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them. -- Eric Niebler BoostPro Consulting www.boostpro.com

13 40

Re: [boost] [tree] Reviving the tree library
by Cromwell Enage 09 May '11

09 May '11

--- On Fri, 5/6/11, Rene Rivera wrote: > On 5/6/2011 4:22 PM, Cromwell Enage wrote: > > What are your thoughts on a generalized depth-first > > iterator that also indicates whether it's currently > > in pre-order traversal mode, post-order traversal mode, > > or neither? I've found it useful for implementing > > scene graphs, for example. > > The goal was to make it possible to have any kind of > iteration. The ones in the TR are the simple common > ones. So yes, other iterations would be good to add. > I'm all for generalization. Are you thinking of the > static kind, as in traits, etc.? Or are you thinking > of something run-time? I was originally thinking of run-time generalization, i.e. the depth-first iterator being a functional superset of pre-order, post-order, and in-order iteration. But now that I look at the implementation, it might not necessarily be so. For a simple illustration, consider this ASCII rendition of the following tree: ___B +--+--+ A_____C If this were stored in a sorted binary tree, one might expect binary_tree::iterator to output the elements in this order: A B C However, if we expect an unsorted nary_tree::iterator to behave the same way (in-order, in this case), then what is the correct output for the following tree? _________I +-----+--+--+-----+ A_____E_____O_____U My current depth-first iterator would output the following: I pre_order A pre_order A post_order E pre_order E post_order O pre_order O post_order U pre_order U post_order I post_order One could filter by pre_order or post_order to obtain the corresponding output, so in that respect my depth-first iterator would be a functional superset. However, it traverses every node exactly twice, and definitely not in the same way as a sorted binary_tree::iterator. Therefore, while I agree that my depth-first iterator could make a fine addition, it may not necessarily serve well as an nary_tree::iterator. Thoughts? Cromwell D. Enage

1 0

[lexical-cast] New maintainer
by Antony Polukhin 09 May '11

09 May '11

Alexander Nasonov and Kevlin Henney gave me their permissions to become a new maintainer of Boost.LexicalCast library. Plans for the nearest future: 1) fix inspection program warnings (missing licenses, copyrights, non ascii chars ...) 2) contact with bug reporters, and fix bugs if they still exist 3) add unit tests and performance optimizations If somebody has some advices, comments or wishes, I would be glad to hear them. 2011/5/9 Kevlin Henney <kevlin(a)curbralan.com>: > Antony Polukhin <antoshkka(a)gmail.com: >> There are some bug fixes in trunk and performance optimizations, that >> can not make their way to release. And there is no accepted >> Boost.Convert library, that can do better than lexical_cast. >> >> Alexander Nasonov, the current maintainer of lexical_cast, wrote that >> he has no time for maintaining lexical_cast and that he has no >> objections against new maintainer.( That was in thread '[boost] >> [lexical-cast] version of lexical_cast in 1.46.1 is quite older than >> in trunk'). >> >> If you don`t mind, I`d like to become a new maintainer of >> lexical_cast. I`ve already talked with Alexander, he gave me a short >> introduction of how to maintain and what changes can be accepted into >> the library. He also advised to talk to you. > > Yes, I would be happy for you to do this, if you want to run initial changes > by me and/or Alexander. > > Antony Polukhin <antoshkka(a)gmail.com: >> Would you be so kind to give me some advises and tell more, about the >> official procedure of becoming a maintainer? > > I don't think there is an official process for becoming maintainer, other > than the original author and/or the current maintainer saying "You are now > the maintainer!" :-) > > And please feel free to ask me any questions about the requirements or > design intent. > > Antony Polukhin <antoshkka(a)gmail.com: >> Is there some requirements, not described in N1973 that the library >> must follow to? > > No, we had no plans for any additional features, only fixes to bugs and > improvements in performance. The functionality is at a point where it is > stable. > > So, congratulations: You are now the maintainer! > > Regards, > > Kevlin

1 0

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Mathias Gaunard 09 May '11

09 May '11

On 05/05/2011 01:37, Raffi Enficiaud wrote: > Hi all, > > Sorry for bothering with this. I recently encountered some problems in using > boost.lambda with Visual 2010 Express, and need some clues for solving the > issue (there are many ways around of course). > I simply want to accumulate the values of a std::map, and I thought using > lambda to access the second member of the map iterator was appropriate. Here > is the piece of code: > > typedef std::map<T1, unsigned short> m_t; > m_t m ; // fill m > double acc(0); > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& > m_t::value_type::second); > > The last line does not compile on Visual (it does on GCC), I have to add a > typedef: > > typedef typename m_t::value_type aa; > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& aa::second); > > Which one is "more correct" ? It's one of the annoying MSVC bugs. MSVC doesn't like it when you chain nested names in template contexts.

1 0

[release] Adding more documentation to the release process
by Daniel James 08 May '11

08 May '11

Hi Beman, At the moment the release doesn't include the geometry documentation which is at libs/geometry/doc/html. I've being creating a new file, boost-release-docs.7z which includes both the main documentation and the geometry documentation (it's a new file because it's zipped from the root, rather than from the doc directory). The attached patch should change the script to use that, and fix copying the documentation - this will also allow us to easily add other documentation at a later date. It's copying to the boost root directory. If you'd rather keep things contained it could use repeated calls to xcopy for the relevant directories, although that would require changing the scripts every time some new documentation is added. Does it look okay to you? Daniel

2 1

[multi_index] feature proposal: member keys and typeless specification of keys
by JOAQUIN M. LOPEZ MUÑOZ 08 May '11

08 May '11

Hi all, This is a proposal for inclusion of two new features into Boost.MultiIndex, mem_key and BOOST_MULTI_INDEX_AUTO_KEY. Consider the following: struct foo { int x; int bar(); int baz()const; }; typedef multi_index_container< foo, indexed_by< ordered_unique<member<foo,int,&foo::x> >, ordered_unique<mem_fun<foo,int,&foo::bar> >, ordered_unique<const_mem_fun<foo,int,&foo::baz> > > > multi_t; Note that we have to use member, mem_fun or const_mem_fun depending on the kind of key used. mem_key allows for a uniform specification syntax: typedef multi_index_container< foo, indexed_by< ordered_unique<mem_key<int foo::*,&foo::x> >, ordered_unique<mem_key<int (foo::*)(),&foo::bar> >, ordered_unique<mem_key<int (foo::*)()const,&foo::baz> > > > multi_t; This in itself gains us relatively little; but if we have a C++11 compiler with decltype, BOOST_MULTI_INDEX_AUTO_KEY can use mem_key in a way that dispenses with the need for specifying the type of the key! typedef multi_index_container< foo, indexed_by< ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::x)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::bar)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::baz)> > > multi_t; Some requests and questions: 1. If you're interested in these features, please download the attached mem_key.hpp file, play with it and report on successful/problematic usage. 2. Do you think this is worth including in Boost.MultiIndex? 3. Proposals on the naming scheme? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

3 6

[provocative] Whom did the SFC pay to list boost developers as a whole in "Current Member Projects"?
by Alexander Terekhov 08 May '11

08 May '11

http://sfconservancy.org/members/current/ (Current Member Projects) "Boost provides free peer-reviewed portable C++ source libraries. Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. Boost aims to establish existing practice and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report ( TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2." The context: (pacer) 03/23/2011 192 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from David Leichtman dated 3/23/2011 re: Requesting that the Reply and Kuhn Declaration be stricken, or in the alternative, that the Court consider Best Buy's responses to these new theories and arguments. ENDORSEMENT: Defendant's request is granted. The Court will consider Best Buy's response to the new issues raised in Plaintiffs' Reply, as set forth in this letter. So Ordered. (Signed by Judge Shira A. Scheindlin on 3/23/2011) (jpo) (Entered: 03/23/2011) 04/14/2011 193 OPINION AND ORDER. For the reasons in this opinion and order, plaintiffs' motion to join WD is denied. The Clerk of the Court is directed to close this motion (Docket No. 133). (Signed by Judge Shira A. Scheindlin on 4/14/2011) (rjm) (Entered: 04/15/2011) 04/26/2011 194 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from Emmett J. McMahon, dated 4/25/2011, re: Counsel for the defendant Best Buy Co., writes to request a pre-motion conference regarding a motion to strike Plaintiffs' claim for "actual damages and any additional profits of [Best Buy] incurred as the result of infringement." ENDORSEMENT: Request granted. A premotion conference will be held on May 6 at 2:30. So Ordered. (Pre-Motion Conference set for 5/6/2011 at 02:30 PM before Judge Shira A. Scheindlin) (Signed by Judge Shira A. Scheindlin on 4/25/2011) (lnl) (Entered: 04/26/2011) (details) http://www.terekhov.de/192.pdf http://www.terekhov.de/194.pdf Suggestion: Please remove boost from http://sfconservancy.org/members TIA. regards, alexander.

9 22

[GSoC] Getting started
by Andrew Sutton 07 May '11

07 May '11

Hello GSoC students and mentors, Students, if you haven't contacted your mentor, now would be the time do so. Mentors, if you haven't heard from your students, you need to try to get in touch with them. If anybody is having trouble getting a hold of their student or mentor, please let me know. During the "Getting to Know You Phase", you should be doing two things: 1. Defining goals and expectations for the summer and 2. Starting to get up to speed with Boost's development environment Remember, that there is a midterm review. It is usually a good idea to set concrete midterm goals in order to ensure that your project is moving forward. Also, the source code of your project MUST be available for review by both your mentor and the community at large. Basically, this means you need to have it publicly hosted. The obvious solution is to house the project in the Boost Sandbox (http://svn.boost.org/svn/boost/sandbox/SOC/2011/) You will probably need to request write access from the Boost owners (boost-owner(a)lists.boost.org) Send them an email. If your project is already hosted online (independently or as part of another project), then we need to know where it is. Please send an email to the list describing how we can check out the source code of your work. I will add the addresses of these projects to the Boost-GSoC wiki page so other interested parties can find them. That's it for now. Good luck! Andrew

3 2

[Review] Boost.Convert, review manager analysis
by Edward Diener 07 May '11

07 May '11

As previously stated Vladimir Batov decided to withdraw his library at the end of the review period from consideration for inclusion into Boost and I had announced this and the fact that because of this the library would not be accepted. Nonetheless I want to give my analysis of the reviews and the issues both pro and con of the reviewers. I also want to give some of my own thinking on these issues. There were few reviews of the library but much late discussion in the final day of the review period and just afterward. There were 2 reviews which voted to accept Convert ( Artyom Bellis, Alfredo Correa ), 3 reviews which voted not to accept Convert ( Jeroen Habraken, Thomas Heller, Hartmut Kaiser ), 1 review which would have accepted Convert but qualified that only if lexical_cast could not be extended instead ( Rob Stewart ), 1 review which would have accepted Convert with large scale changes ( Gordon Woodhull ), and one mention, not a formal review, of acceptance until something else came along but with perhaps a later change of mind ( Paul Bristow ). There was also one review sent to me personally by Barend Gehrels, after Vladimir Batov withdrew his library, which voted not to accept Convert. There were also a number of people who raised doubts and objections to Convert in various ways without giving a formal review. It is all these issues raised by reviewers and commenters I want to discuss next. Vladimir Batov was responsive to nearly all of those issues but I want to enumerate them and give my own thoughts about them as I read reviews and comments. A number of people wanted lexical_cast to be extended instead of a new library. This certainly is a valid viewpoint. But I believe that the lexical_cast library is set as it is until someone takes it over from its original author and is willing to change it. I think it is better to review the library under discussion rather than to hope that something else can be changed in the future. There was an issue of the basic syntax which many people did not like. Instead of the syntax of 'convert<dest>::from(source)' there were a number of people who wanted to see 'convert<dest>(source)' instead, largely becaused it matched the 'lexical_cast<dest>(source)' syntax. Vladimir Batov explained why he used the syntax he did. I think in this case it is reasonable. Again this is an issue in relation to lexical_cast, and I saw no real significant difference between the syntaxes on a basis of practical use. The main issue brought out by many people is whether a single function can encompass successfully all of the functionality which Convert wished to encompass and whether this functionality both worked smoothly with everything others wished to do with the functionality. Here there were many valid objections and I will attempt to enumerate them: 1) The return value of the convert function is really many different returns, and this is done through implicit conversions of the actual return type. This was mentioned most eloquently by Thomas Heller. It is quite natural to assume that the return value of a successful call to 'convert<dest>::from(source)' would be a 'dest' object but instead it is a value which has an implicit conversion to 'dest'. This works when passing the value to ordinary functions but does not when passing the value to template functions. As Vladimir Batov mentioned one can use the 'value()' member function of the return value, and presumably also one can use a 'static_cast<dest>' also, to force the exact 'dest' object to be passed, but I also viewed this as a negative way to work, and a very valid objection to the way Convert was designed. To me it was not just a matter of confusion to the end-user but of a naturalness of use. A convert-type interface should have some function where, if the convert is successful, the actual result of the conversion is returned, and not some intermediate value with an implicit conversion. 2) The Convert library uses a stream-based method to do conversions but wanted to leave the door open for other methods. Part of the extended syntax of the library works with stream manipulators and locales. A very valid point was brought up, again by Thomas Heller, that it is not clear how the extended syntax is supposed to work with and affect non-stream based specializations of the basic convert template. Even the method of extending the library in this way, rather than just providing stream-based operators for a given type, is open to much doubt as valid C++ and largely left unexplained in the documentation. 3) The syntax for the stream-based and locale additions to the library's functionality was found odd by many people. The term 'wacky' was often used and Vladimir Batov did defend his choice about it well. Nonetheless it is a valid issue to consider whether the extended syntax is easy for a person to use. I found the syntax for using iostream manipulators quite natural, and the syntax for locales and other functionality such as throwing behavior less natural. Again I do not want to get too caught up in syntactical issues but I did understand the issues brought up by others regarding this. 4) The method of using the convert function in algorithms was criticized. Some people expressed their wish that a placeholder syntax, as used by other Boost libraries, be used. I actually found the way Convert does this as pretty elegant, there were two syntaxes which worked, but could understand others liking for the placeholder syntax. 5) The use of a default value, the issue of a default constructor, and the differing results when a conversion fails or not, received much discussion, especially at the official end of the review period and afterward, and I appreciate reading all of the discussions. I do not want to specifically go into each one, other than to say that I think this has basically to do with the issue of having a single function do everything which could not easily cover all the different scenarios mentioned for actual use. There were other valid concerns which are related to just a need for more complete documentation. Vladimir Batov responded to most of them. Here I will enumerate them: 1) Rob Stewart in his review mentioned many documentation corrections related to grammar, spelling etc. 2) What locale is being used by default is not explained. 3) The reference is very incomplete. 4) The section for extending the library is unclear and incomplete. Finally there were valid concerns relating to getting Convert to work properly. Some of these related Convert and lexical_cast and noted the differences. A few others mentioned things which just did not work properly in the actual conversion and again Vladimir Batov said he would look at these issues. Barend Gehrels sent me a late review, which he did not want to post to the mailing list because Vladimir Batov had already withdrawn is library, in which he said that he had some technical problems adapting a Boost.Geometry type to work with Convert. I think these are all technical issues which can be resolved. Many other people had specific incisive remarks during the review period but I can not list them all. That does not mean those remarks were ignored by me in any way, as I read and attempted to digest what everyone had to say. Final remarks: I would like to bring some clarity to the issues which may have forced Vladimir Batov to essentially withdraw his library at the end of the review period from consideration and which led to much comment and criticism about the library. This is my purely personal take on the library, but it is based on my technical understanding of the issues involved. The main issue with the library is that the 'single function fits all scenarios' works much less well in practical use than the author supposed, even as I understood the reason for simplicity which caused him to pursue this path. There really needs to be a function that simple returns the converted value upon success. Overloaded versions of that function, or differently named functions, can return other specific things. Where there is a great attraction to a return value which can be implicitly converted to other values, I think this attraction given practical use is somewhat illusory. While I did not enjoy some of the harsher remarks made by Thomas Heller in his review of the library about the design of Convert ( and I do not think he really meant them as harshly as they may have sounded ) he did rightly point out that the 'overloaded' return value is an impediment to a cleaner design which would allow one to use the right convert function given the possibilities which the library wants to accomplish. I know there has been many subsequent discussions about a set of functions that can replace the single function in Convert depending on how Convert can be used, and I do not myself want to get in the middle of this debate, but once there is an understanding of what needs to be done, I really think the library can be designed to appeal to end-users in a better way. The second issue in my mind is that the library attempts to do too much given the way it was designed. If the focus is simply a library which does stream-based conversion between strings and objects ( both ways ) I personally think it would be much better. Once you look for non-stream based conversions you have to consider more carefully how the stream-based syntax and locales should be integrated with the library. Once you look for type to type conversions rather than string to type and type to string conversions you have to design a good general facility for specifying how this is done within the functions you provide. This is a much bigger job of thinking about design, unless you are simply providing a very generalized shell with little real functionality built-in. I am not saying the author of the library has not thought about these issues, but my impression is that they have not been addressed carefully. Just in case anyone wanted to know, and also so that Vladimir Batov does not feel so bad about withdrawing the library from consideration at the end of the review period, I would have rejected the library for inclusion into Boost given the reviews and comments of others and my own perceptions of the issues involved. But I think the author has still done a fine job and is close to having a library which could be included as a part of Boost. Although it is hard work, it has been a pleasure to be a review manager of this library and I thank everyone involved and especially the author of the Convert library himself. Edward Diener

2 1

[Block Pointer] Docs
by Phil Bouchard 06 May '11

06 May '11

Hi, Sorry for the repetitive emails and thanks to Gregory Crosswhite regarding it but I have improved the user-friendliness of the utility: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/overvi… Please let me know if there's anything unclear. Thanks, -Phil

2 6

[PBGL] Distributed adyacency_list memory allocation
by Cosimo Calabrese 06 May '11

06 May '11

Hi to all, I'm working on WinXP, VS2010, boost 1.46.1. I've writed this short program: //---------------------------------- #include <boost/graph/use_mpi.hpp> #include <boost/graph/distributed/mpi_process_group.hpp> #include <boost/graph/distributed/adjacency_list.hpp> using boost::graph::distributed::mpi_process_group; typedef boost::property<boost::vertex_distance_t, long, boost::property<boost::vertex_name_t, std::string > > vertex_prop; typedef boost::property<boost::edge_weight_t, long > edge_prop; typedef boost::adjacency_list< boost::vecS, boost::distributedS<mpi_process_group, boost::vecS>, boost::directedS, vertex_prop, edge_prop > Graph; typedef boost::graph_traits<Graph>::edge_descriptor EdgeDescriptor; typedef boost::graph_traits<Graph>::vertex_descriptor VertexDescriptor; int main(int argc, char* argv[]) { boost::mpi::environment env(argc,argv); Graph g( 10 ); return 0; } //---------------------------------- When I launch it, every process allocates about 1 GB of memory. Why it allocates all that memory? Is it normal? Is there any tuning to the PBGL framework that I must made? I use it on a 2-core machine, and the command that I use is: mpiexec -n 2 .\test.exe I've tried with openMPI 1.4.3 and Microsoft HPC Pack 2008, but it seems irrilevant. Thanks in advance, Cosimo Calabrese.

2 1

Extending multi_index_container hash tables
by Vladimir Voznesensky 06 May '11

06 May '11

Hello there. Current implementation of hashed index has, at least, two issues, preventing me from re-using it in some places. First, the time for unlink operation in multi_index/detail/hash_index_node.hpp is O(m) where m is a occupancy of the given bucket. I'ts usually ok for unique index, but seems to hit performance of removing item in a non-unique index. It's all because of using single-linked list instead of double-linked one. Second, there is no possibility to use internal order of the records in the bucket, i.e. operations like popping the last element in the bucket's list. Such feature could be useful for, for example, priority queues. It could be realized by using such double-linked (or extra pointers in a bucket structure). Sure, I could get the current realization and write my own index, but it seems wiser to extend the current implementation to support custom bucket container or custom node as a template parameter. Thanks in advance. VV

2 1

Re: [boost] [review] string convert
by Vicente BOTET 06 May '11

06 May '11

Hi, are we discussing here a generic interface from type-to-type or one that uses an intermediary stream to make the conversion? If it is the first I could accept names as convert_cast or convert_to. If it is the second, I don't think it is appropriated to use this generic form and something in the name must recall this feature. lexical_cast is used for exactly this purpose and the name is appropriated. How could we rename the Boost.Convert library? Boost.StreamConvert? and the operations? Best, vicente

4 9

[autoindex] Rationale Question
by Artyom 06 May '11

06 May '11

Hello, It is not a review but rather questions about this tool rationale. Form the very brief look into AutoIndex documentation I see. > ... AutoIndex will automatically scan one or > more C/C++ header files and extract all the > function, class, macro and typedef names that > are defined by those headers, and then insert > the <indexterm>s into the Docbook XML document for you. > However, there is a tool Doxygen that already does this. Doxygen is fully capable system for indexing source files and providing references for them. For example: http://cppcms.sourceforge.net/boost_locale/html/namespacemembers.html http://cppcms.sourceforge.net/boost_locale/html/namespacemembers_func.html So there is a well debugged, tested, supported indexing tool (Doxygen) that as far as I know works fine and is already used by Boost. So the question are 1. How does it differs from Doxygen indexing? I'm not talking about the integration with various pars of Boost documentation toolchain but rather what it does differently. 2. Why have you decided to develop entirely new tool instead of using existing one. I probably miss some points but I rather see a great tool Doxygen that already does many things and does them well but still Boost creates its own tools (and this does not happen first time) Thanks, Artyom

3 2

[xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

10 17

FW: Registration Available
by Hartmut Kaiser 06 May '11

06 May '11

FYI... Regards Hartmut --------------- http://boost-spirit.com > -----Original Message----- > From: boostcon-plan(a)googlegroups.com [mailto:boostcon- > plan(a)googlegroups.com] On Behalf Of Marshall Clow > Sent: Friday, May 06, 2011 11:25 AM > To: boostcon-plan(a)googlegroups.com > Subject: Registration Available > > Oliver Mueller <oliver.mueller(a)gmail.com> has discovered that he will not > be able to attend BoostCon. > Unfortunately for him, it is well past the refund deadline (which was > 4./14), so he's looking for someone to use his registration. > > If you know someone who could take advantage of a deal on admission, they > should get in touch with Oliver and work something out. > > -- 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

1 0

Re: [boost] [Boost-users] [Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

On 6 May 2011 10:33, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 5/5/2011 9:08 PM, Vitaly Budovski wrote: >> Greetings, >> >> On 28 April 2011 12:09, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >>> Thanks for this! >> >> Apologies for the long delay in replying. >> >>> >>> A couple of comments: >>> >>> 1) Is there a reason why you created separate components instead of simply extending the existing set of binary parsers/generators? >> >> It seemed like it would be a lot more work. I'm guessing I would need >> to add a new template parameter or maybe use the preprocessor, since >> the classes have a few integer<> types inside. Can you suggest a >> better way? >> >>> >>> 2) What's the rationale for not using/extending the endian classes in Spirit, but providing your own set of independent endian types? >> >> See response above :) Another thing I wasn't too happy with was the >> fact that they are in the integer namespace. Perhaps they should be >> moved out of there, since endianness doesn't apply only to integers. >> >>> >>> 3) If this is to be included into Spirit we'd need the corresponding docs as well. >> >> A few more test cases couldn't hurt either. I discovered I missed an >> asterisk in the generate_to line of bin_float_generator. >> Is there a guide for adding docs to boost? > > Boost Spirit uses quickbook. Please check out the Spirit docs. > Here's a link to quickbook: > http://www.boost.org/doc/libs/1_46_1/doc/html/quickbook.html > > Vitaly, the proper forum for this is the Spirit general or devel mailing list: > See Boost.Spirit lists here: http://www.boost.org/community/groups.html > Can we please move the discussions there? > > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://boost-spirit.com > Thanks Joel. Moving conversation to more appropriate location. Cheers, Vitaly

1 0

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

[foreach] Warning with gcc-4.6.0 and -Wconversion
by Philipp Reh 05 May '11

05 May '11

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously. Here is a simple program to reprdouce this: #include <boost/foreach.hpp> #include <iostream> #include <ostream> #include <vector> typedef std::vector< int > int_vector; int_vector const test() { int_vector ret(2, 2); return ret; } int main() { BOOST_FOREACH( int_vector::const_reference ref, test() ) std::cout << ref << '\n'; } This prints the following warning: test.cpp:21:2: warning: choosing ‘boost::foreach_detail_::rvalue_probe<T>::operator boost::foreach_detail_::rvalue_probe<T>::value_type() [with T = const std::vector<int>, boost::foreach_detail_::rvalue_probe<T>::value_type = const std::vector<int>]’ over ‘boost::foreach_detail_::rvalue_probe<T>::operator T&() const [with T = const std::vector<int>]’ [-Wconversion] test.cpp:21:2: warning: for conversion from ‘boost::foreach_detail_::rvalue_probe<const std::vector<int> >’ to ‘const int_vector’ [-Wconversion] test.cpp:21:2: note: because conversion sequence for the argument is better I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

3 3

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

result_of overloaded member function?
by Arno Schödl 05 May '11

05 May '11

Hello, is there a way to get the result type of an overloaded member function? Something like: template< class T, class A > typename boost::result_of< T::func(A) >::type invoke( T& t, A& a ) { return t.func(a); } Thanks for help, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 3

[Convert] Not a review
by Phil Endecott 05 May '11

05 May '11

Dear All, I've not looked at this library in anything like enough detail to write a proper review, though I have followed a fair amount of the discussion both during the review and during previous discussions of a "better lexical_cast". My view comes down to this: there are zillions of different ways of doing this (both syntax and semantics) and no solution can keep everyone happy (as evidenced particularly by the previous discussions). But that doesn't matter, because every single C++ programmer is capable of writing their own conversion functions that work exactly how they want them to work, if they have the right building blocks. The building blocks are things like C's strto*(), etc. Personally, I prefer thin wrappers like these ones: template <typename ITER> long int strtol(ITER begin, ITER end) { ... } template <int N> long int strtol(const char (&s) [N]) { return strtol(&s[0],&s[N]); } inline long int strtol(std::string s) { return strtol(s.begin(),s.end()); } For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations. But I don't suggest that these are going to suit other people. Why should we try to find a "one size fits all" solution to this problem? In my humble opinion, Boost does not need this functionality. Perhaps some of the lower-level "building blocks" would be useful, though - if things like strto*() are deficient. Regards, Phil.

3 4

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Peter Dimov 05 May '11

05 May '11

Raffi Enficiaud wrote: > To this point, I thought that using accumulate would be cleaner: > std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); std::accumulate takes a binary function. It doesn't do s += f(*i) as you seem to think, it does s = f(s, *i). So you should probably pass _1 + &_2->*&aa::second to it.

1 0

howto: boost.lambda + stl on VS 2010 (SP1) ?
by Raffi Enficiaud 04 May '11

04 May '11

Hi all, Sorry for bothering with this. I recently encountered some problems in using boost.lambda with Visual 2010 Express, and need some clues for solving the issue (there are many ways around of course). I simply want to accumulate the values of a std::map, and I thought using lambda to access the second member of the map iterator was appropriate. Here is the piece of code: typedef std::map<T1, unsigned short> m_t; m_t m ; // fill m double acc(0); std::for_each(m.begin(), m.end(), var(acc) += & _1->*& m_t::value_type::second); The last line does not compile on Visual (it does on GCC), I have to add a typedef: typedef typename m_t::value_type aa; std::for_each(m.begin(), m.end(), var(acc) += & _1->*& aa::second); Which one is "more correct" ? To this point, I thought that using accumulate would be cleaner: std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); But I have several compilation errors, and on the top of it: 1>(..)/boost-1_46_1\boost/lambda/detail/member_ptr.hpp(512): error C2296: '->*' : illegal, left operand has type 'const rt0 ' 1> boost/lambda/detail/member_ptr.hpp(622) : see reference to function template instantiation 'RET boost::lambda::detail::member_pointer_action_helper<true,false>::apply<RET,A ,B>(A &,B &)' being compiled 1> with 1> [ 1> RET=unsigned short &, 1> A=rt0, 1> B=rt1 1> ] I do not really understand what rt0/rt1 are. The former should be the iterator::value_type and the latter the pointer to member. Most of all, the call with accumulate looks very similar to the for_each one to me. So, is the problem between the keyboard and the chair ? Best, Raffi

1 0

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[Spirit Karma] Mutable references formed by pass_container in Karma "repeat" tests
by Doug Gregor 04 May '11

04 May '11

There are a few Karma failures using the latest Clang due to the pass_container detail class forming mutable references: http://www.boost.org/development/tests/release/developer/output/dgregor2-bo… I know that at least some compilers (e.g., GCC) don't diagnose mutable references, but this code is ill-formed account to the standard. Someone want to take a shot at eliminating or factoring out the mutability to avoid these mutable references? - Doug

2 1

[Review] Boost.Convert library, last day
by Edward Diener 04 May '11

04 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov ends today, May 2. There have only been a few reviews of the library so the library welcomes reviews. If you are one of the people who have been dissatisfied by the perceived limitations of Boost lexical_cast, or have discussed such limitations on Boost mailing lists in the past, please look at the library and give a review of it, as its intent is to offer a greatly enhanced version of lexical_cast as a new library. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* The Boost Vault is accesible again after being down for most of the week, so you can get the library from the Boost Vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… You can also get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

10 17

Re: [boost] Boost.Locale and the standard "message" facet
by Vicente BOTET 04 May '11

04 May '11

Hi, > Message du 30/04/11 15:48 > De : "Artyom" > A : boost(a)lists.boost.org > Copie à : > Objet : Re: [boost] Boost.Locale and the standard "message" facet > > > Subject: [boost] Boost.Locale and the standard "message" facet > > > > Hi, > > > > I was wondering how Boost.Locale is related > > to the standard message facet which is used > > to translate messages. > > > The standard message catalogs allow to extract > messages by integer identifiers but may use string > identifiers and it is implementation defined > > It is undefined how to load message facets Well implementation defined doesn't mean undefined. > or format them and so on. The formatting can always be done on top of this facet, isn't it? > It does not support plural forms and context. I'm not an expert, but doesn't catalogs and the set parameter can be used for your domain an context? Respect to plural forms, how Boost.Locale manages with locales that have 3 or 4 forms of plurals (If I understood your private mail, Hebrew is an example of this)? I've the impression that Boost.Locale manage simple plurals but not all kind of plurals? BTW, what is the criteria in Boost.Locale to identify a plural form? How your library manage plurals for message that have several parameters? For example translate("%1 hours, %2 minutes, %3 seconds") % h % m % s > It is the most unless facet around. What do you mean? That the scope is reduced? > > Note that the facet > > interface work with integer identifiers > > avoiding all the issues raised by the > > get_text/translate functions > > provided by Boost.Locale. > > > > Use of integer identifiers is the best > way to screw the localization in the software. > > What does 3456 means? Do you really think > it is good to write translate(MY_MESSAGE_OPENING_FILE) Why not? Note that we can also write translate(MyMessage::OpeningFile) if this seems clearer to you > No, never - never - never - never - never > use such "constant" or "integer" identifiers. I understand that some as you can find that the use of integers scale worst than the use of strings as we need to maintain constants unique on a given context, but this can be checked on debug mode. Some time ago when I had to write a localization application, we used integer identifier to log internationalizable messages. This reduced drastically the size of the log. I guess only this advantage was enough to take integers instead of strings, for us of course. An advantage I see is that you need to concentrate all the message id of a set/context in a single file so no need to have tools that parse your code to get the strings to translate. BTW, how do you recover message translation from a domain with your underlying implementation, copy/paste or is there a possibility to have specific files for specific domains, or there is a single translation file by locale? I've not take a look at your implementation yet. Please could you tell me when the translation file is read? Is the file parsed only once and the translations stored on a cache? > Always use natural text. I think your natural language interface lets the user to have the impression that anything is possible, when a lot of limitations seem to be there as other have already commented in this ML. > > Is there any reason Boost.Locale > > could not follow the standard design? > > The standard message catalogs to weak I would like to here the rationale of the standard message design by someone that is aware of it (some pointers will be welcome also). > > What are the advantages of the Boost.Locale design? > > > > 1. Defined way to load and format catalogs You could provide a defined way on top of this facet, isn't it? > 2. Support of pural forms Plural forms can be designed on top of the message facet? > 3. Support of message-context As I said, I suspect that the set parameter is interpreted as your context. > 4. Using natural language identifiers as keys See below. This is not always an advantage, and as far as I see adds some constraints on the interface so the tool can take care to automatically extract the strings to translate. > 5. Convenense interface What do you mean? Could you compare both? > More? Well, I think that it would be great if you can add a complete comparison of the interfaces and a rationale why you think your design is superior on the documentation. Best, Vicente

2 7

[range] as_literal always returning iterator_range
by Tobias Germer 04 May '11

04 May '11

Hi all, I think there is a problem with the behavior of boost::as_literal. If I got it right, it is supposed to create an iterator_range from null-terminated strings, which is fine. However, it also creates iterator_ranges from exisiting ranges, i.e., it converts general ranges to iterator_ranges. I think as_literal should fall back to identity (i.e., just return its argument) if its argument is already a range. With the current behavior, the type information of the range is lost. This is a problem if I write generic code and want to dispatch several cases based on the type of the range. Consider the following example: ------------------------------- template<class Rng> void f( Rng const& r ) {...} template<class T> void f( iterator_range<T*> const& r ) {...} void f( std::string const& s ) {...} void f( std::vector const& v ) {...} template<class Rng> void g( Rng const& r ) { f(as_literal(r)); ... } ------------------------------- Function g() accepts general ranges as well as zero-terminated strings. It dispatches its argument using the type of the range and the overloads of f(), in order to execute special code for some ranges like strings and vectors. (In my particular case, I have special treatment for ranges of contiguous memory.) This is not possible anymore after calling as_literal, because it always returns an iterator_range. Wouldn't it be better to return the original range, for example like this: template< class Rng > typename enable_if< has_range_const_iterator<Rng>, Rng &>::type as_literal (Rng& r ) { return r; } Regards, Tobias -- Dr. Tobias Germer | tgermer(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 2

Boost announce mailing list messages
by Edward Diener 04 May '11

04 May '11

My messages to the Boost announce mailing list, despite being the review manager for the Boost.Convert library, are being ignored. Why is this ? I was able to post an initial announcement on the Boost announce mailing list when the review of the Boost.Convert library started, but my message to that mailing list, when the Boost vault was down and I wanted to alert uses to the subversion URL I had created for the Boost.Convert library, never got posted on the Boost announce mailing list. Now that I have sent another message to the Boost announce mailing list, signalling the result of the Boost.Convert library review, it is again being ignored.

2 1

boost in linux repository
by Krzysztof 04 May '11

04 May '11

When the newer version of boost library is expected to be in linux repository? Now, it has version 1.42. -- Regards Krzysztof J.

3 3

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

Re: [boost] [asio] Randomly having problems reading from the socket
by Torben Wiggerich 04 May '11

04 May '11

Hi Jinqiang, thanks for your answer. What I forgot to mention was that I'm using the localhost for the socket connection. So there shouldn't be any errors caused by the physical network, I guess. I changed the code to evaluate the 'ignored error'. But an error never occurs there . It just falls asleep for 5 seconds. Kind regards Torben > > > -------- Original-Nachricht -------- > Betreff: Re: [boost] [asio] Randomly having problems reading from the > socket > Datum: Tue, 3 May 2011 08:57:27 +1000 > Von: Jinqiang Zhang <jasonzha(a)gmail.com> <mailto:jasonzha@gmail.com> > Antwort an: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > An: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > > > > Hi Torben, > > Firstly I claim I always use async way of asio, so I don't get the same > problem as yours. But for your code, I might suggest, because you are > transferring big chunk of data, if network condition is bad, you might get > some error, so maybe you want to see the 'error' while not use 'ignored > error' ? > > cheers, > Jinqiang > > On Mon, May 2, 2011 at 10:28 PM, Torben Wiggerich<torben.wiggerich(a)nisys.de > > <mailto:torben.wiggerich@nisys.de> wrote: > > > Hi all, > > > > I have some problems using the boost.asio.read for a TCP-socket. So far it > > works fine, but it randomly stops the transfer for at least 5 seconds. > > To resolve the error I used a simple synchronous server and client from the > > boost examples and modified it too send a larger amount of data. (307400 > > Bytes; this size comes from the program I'm trying to get run). On the > > client side I also changed the reading from the socket to read the complete > > data with boost.asio.read and transfer_all as argument. > > > > Both, server and client, measure the time for sending and reading to the > > socket and will give an error if it needs more than 1 second. > > > > Here is the sourcecode for the server: > > > > #include<iostream> > > #include<string> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main() > > { > > try > > { > > boost::asio::io_service io_service; > > > > tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); > > > > tcp::socket socket(io_service); > > acceptor.accept(socket); > > > > unsigned char * array = new unsigned char[307400]; > > > > for (;;) > > { > > boost::system::error_code ignored_error; > > > > ptime startTime = microsec_clock::universal_time(); > > > > boost::asio::write(socket, boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), ignored_error); > > > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > > > My client sourcecode: > > > > #include<iostream> > > #include<boost/array.hpp> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main(int argc, char* argv[]) > > { > > try > > { > > if (argc != 2) > > { > > std::cerr<< "Usage: client<host>"<< std::endl; > > return 1; > > } > > > > boost::asio::io_service io_service; > > boost::asio::ip::tcp::endpoint endpoint( > > boost::asio::ip::address::from_string( argv[1] ), 8002 ); > > > > tcp::socket socket(io_service); > > boost::system::error_code error = boost::asio::error::host_not_found; > > socket.connect( endpoint, error ); > > if (error) > > throw boost::system::system_error(error); > > > > int counter = 0; > > unsigned char* array = new unsigned char[307400]; > > for (;;) > > { > > boost::system::error_code error; > > > > ptime startTime = microsec_clock::universal_time(); > > size_t len = boost::asio::read( socket, > > boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), > > error ); > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( error ) { > > printf( "body read error %s\n", error.message().c_str() ); > > } > > > > if ( counter % 5000 == 0 ) { > > std::cout<< "passed: "<< counter<< "\r"; > > } > > ++counter; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > To reproduce the error just let it run for a while. It can take up to 30 > > minutes or even more... > > After a while it will produce the line: "ERROR needed too much time: > > 5007ms". Maybe with slightly different times, but all around 5 seconds. > > I tested it on different machines with Windows Vista and Seven. > > > > So am I'm doing sth. wrong? Is the reading from the socket correct? > > > > I'm using boost version 1.44. > > > > Kind regards > > Torben Wiggerich > > > > _______________________________________________ > > Unsubscribe& other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe& other changes:http://lists.boost.org/mailman/listinfo.cgi/boost > > > ----- > eMail ist virenfrei. > Von AVG uberpruft -www.avg.de <http://www.avg.de> > Version: 10.0.1209 / Virendatenbank: 1500/3610 - Ausgabedatum: 02.05.2011 >

1 0

[config] Regression tests and warnings
by Edward Diener 04 May '11

04 May '11

It appears that the config regression tests treat all warnings as errors. Where is this specified in the jamfiles for config ? I need to run the config regression tests where -Wno-variadic-macros is defined for gcc, so that the warnings for using variadic macros are turned off and therefore no errors occur. What is the best way of modifying the config regression tests to do this ?

2 3

Porting boost::lexical_cast tests to boost::convert
by Jeroen Habraken 03 May '11

03 May '11

Hi, Since boost::convert is promoting itself as an alternative to boost::lexical_cast I decided to port the boost::lexical_cast test suite (which can be found in BOOST_ROOT/libs/conversion/lexical_cast_test.cpp) to boost::convert. I've simply replaced lexical_cast<T>(U) with convert<T>::from(U) and bad_lexical_cast with std::invalid_argument, whether this is a valid approach I'm not sure. To actually get the test suite to compile for boost::convert I had to comment out a lot of them and even then there are quite a few failures. This needs to be looked at (I've attached the code), what are actual boost::convert failures (both at compile- and runtime) and what is caused by my porting? Regards, Jeroen

2 1

[Review] Boost.Convert library has ended
by Edward Diener 03 May '11

03 May '11

The review period for the Boost.Convert library has officially ended. I will continue to read posts about the library while I make my review decision, so please do not stop discussing the library as appropriate because the review period has ended. I have received one personal request for a late review, and I am willing to accept any other requests for a late review to be made through Wednesday and posted to the mailing list, but I will not consider any other late review in my decision unless someone requests it of me personally. I know this is a fine line between an official review and just comments about what others have said before, but I need to make my decision based on some finite set of reviews and their subsequent discussion. I would like to thank everyone who has officially reviewed Boost.Convert as well as all who have made subsequent comments. The more input received, the easier it becomes for me as a reviewer to make a final decision. I would also like to thank the implementer of the Boost.Convert library, Vladimir Batov, for his willingness to address issues, answer criticism, and engage in discussion about his library. My review decision should be made and posted to the mailing list no later than by the end of Sunday, May 8.

4 3

[Review] Boost.Convert library, new subversion URL
by Edward Diener 03 May '11

03 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts today, April 23, and is scheduled to last through May 2. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* Normally you can find Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… However because the boostpro web site is having problems and will likely be down for the weekend, I have put the library into the Boost sandbox temporarily, since the Boost sandbox is up. So you can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. This is exactly the same as the vault with the files unzipped. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

12 19

[Block Pointer] Review Request
by Phil Bouchard 03 May '11

03 May '11

Hi, I made the requested corrections to the Block Pointer, I've added automated tests and its corresponding Jamfile. The tests can be found here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/test/block… https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/test/block… Once again the documentation can be found here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/tutori… Now I'm pretty sure I haven't forgotten anything and I am requesting a review. Thanks, -Phil

5 31

Re: [boost] [BOOST CORE C++ Feature] the super or base keyword for C++
by tymofey 03 May '11

03 May '11

>>I was wondering if it makes sense to add the well known super or base keyword to the C++ language in a generic way. C++ has multiple inheritance, while java and C# do not, so super would be ambigous.

8 14