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

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