- Boost - lists.boost.org

warning about metacomm darwin results
by JOAQUIN LOPEZ MU?Z 13 Sep '04

13 Sep '04

The metacomm darwin results use a toolset named gcc-3.1-darwin. Yet, its corresponding config_info test (http://tinyurl.com/5afdp) reveals that the version of GCC used is 3.3, and not 3.1; this could be misleading. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[ANN] xpressive 0.9
by Eric Niebler 13 Sep '04

13 Sep '04

It's been nearly a year since I first announced my intention to build a new regular expression engine. It has finally reached a point where I am comfortable recommending it for general use. << xpressive 0.9 >> http://boost-sandbox.sourceforge.net/libs/xpressive - What is it? It is a regular expression engine which allows you to author regexes as expression templates (like Spirit) *or* as strings (like Boost.Regex). When written as an expression template, the regex is syntax-checked at compile-time and statically bound for maximal inlining and optimization. (See http://tinyurl.com/6k9p8 for more detail.) Also, regular expressions can nest and call each other recursively, which gives you the power of a context free grammar. That makes it appropriate for simple parsing tasks. (See http://tinyurl.com/4enn4 for more detail.) - What's the interface like? xpressive is a Boost.Regex work-alike. It follows the regex standardization proposal closely, but not too close! You can read about all the differences in xpressive's documentation. The domain-specific embeded language for xpressive is heavily influenced by Spirit. - Where can I read more? xpressive's documentation is online at: http://boost-sandbox.sourceforge.net/libs/xpressive - Where can I download the code? You can get the xpressive zip archive at: http://boost-sandbox.sourceforge.net/xpressive.zip It contains the source code and the documentation in PDF format. Alternatively, you can get xpressive directly from the boost-sandbox. Source code is at /boost-sandbox/boost/xpressive, and the regression test and documentation are at /boost-sandbox/libs/xpressive. Note: this is version 0.9. Check out the "Not Yet Implemented" section in the documentation to see why. I'll be working towards v1.0 in the coming weeks and months, but I am confident at this point that the interface is not likely to change. What's there is stable and solid and ready for (ab)use. Original announcement of xpressive: http://lists.boost.org/MailArchives/boost/msg55623.php Cheers, -- Eric Niebler Boost Consulting www.boost-consulting.com

8 27

[move_ptr] implementation and docs available
by Jonathan Turkanis 13 Sep '04

13 Sep '04

Hi All, A long time ago, I announced that I was working on an implementation of a move pointer: On Wednesday, January 21, 2004 6:30 PM, "Jonathan Turkanis" <technews(a)kangaroologic.com> wrote: > ... My goal is to have the > implementation done tonight. That means it will be done next week. :-) Well, I actually did write the implementation, but never documented it, and finally forgot about it. Recently, Thorsten Ottosen requested a move_ptr implementation, so I cleaned up my implementation from Janurary and wrote some tests and documentation. Here it is: http://home.comcast.net/~jturkanis/move_ptr/ It's based on Daniel Wallin's adaptation of an idea of Rani Sharoni, mixed in with some ideas of Howard Hinnant and Bronek Kozicki. Best Regards, Jonathan

2 6

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > >>AFAICT the docs lack any sort of formalized reference guide, showing > >>interface summaries, what headers to include, requirements, etc. IMO > >>it's unacceptable without that component. Did I miss something? > > > > okay. IIUC, Doxygen will auto-generate these when provided > > javadoc-like comments. > >You won't get Concept documentation from Doxygen unless you take care >to actually write it ;-), and regardless I don't think this can be >done as an afterthought. I would be wary of taking this route unless >your implementation is very simple. It's important to present a >coherent view of the *user interface* that doesn't expose >implementation details. For example, sometimes public inheritance >from some helper class is neccessary as an implementation technique, >and you don't want to expose it, but you need to expose the public >members of that helper. I don't think Doxygen can deal with that. I suppose it depends what you are doing. If you are just inputting/outputting an object, then you don't need to be concerned with how things like boost::io::pairfmt() are implemented. However, you will need to know the object that pairfmt() returns if you want to save that type for use later, e.g.: // note: using new names: // renders the format: ( < a, b, c > | 5 ) io::pair_fmt_t< const char *, io::container_fmt_t< const char * > > my_type_renderer = io::pair_fmt( io::container_fmt().format( "< ", " >" )).format( " | " ); std::pair< std::list< char >, int > data; std::cout << io::sequence( data, my_type_renderer ); // output: ( < a, b, c > | 5 ) NOTE: This is where typedecl/auto comes in useful, making the above example become: auto my_type_renderer = io::pair_fmt( io::container_fmt().format( "< ", " >" )).format( " | " ); std::cout << io::sequence( data, my_type_renderer ); // output: ( < a, b, c > | 5 ) Likewise, you will not need to know how boost::io::formatter_t differs from boost::io::formatter in most cases. However, this becomes important when implementing your own format object (for example, adding tuple rendering support). It's all about context. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

range addition - generic constructor
by Neal Becker 12 Sep '04

12 Sep '04

It is not unusual to need to construct a container from another where one or the other doesn't comply with sequence. When generic code needs to convert to a container of unknown type (e.g., the return container type of a function is a template parameter), a generic constructor is useful, and could be part of range. Here is the idea: #ifndef const_from_range_hpp #define const_from_range_hpp #include <boost/range.hpp> #include <algorithm> #include <boost/numeric/ublas/vector.hpp> namespace detail { template<typename cont_t, typename range> struct construct_from_range_impl { cont_t operator() (range const& r) { return cont_t (boost::begin (r), boost::end (r)); } }; template<typename T, typename range> struct construct_from_range_impl<boost::numeric::ublas::vector<T>, range> { typedef typename boost::numeric::ublas::vector<T> ret_t; ret_t operator() (range const& r) { ret_t v (boost::size (r)); std::copy (boost::begin (r), boost::end (r), v.begin()); return v; } }; } template<typename cont_t, typename range> cont_t construct_from_range (range const& r) { return detail::construct_from_range_impl<cont_t,range>() (r); } #endif Here is a test example: #include "const_from_range.hpp" #include <vector> #include <boost/numeric/ublas/vector.hpp> namespace ublas = boost::numeric::ublas; // simple example int main() { std::vector<int> v (10); ublas::vector<int> w = construct_from_range<ublas::vector<int> > (v); } // more realistic example template<typename cont_t> cont_t F () { std::vector<int> v (10); do_something(); return construct_from_range<cont_t> (v); }

2 6

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Pavel Vozenilek wrote: >"John Torjo" wrote: > > > The FORMAL Review of "Output Formatter" library begins today, > > >I briefly looked on the library and wrote down few >notes. I am especially interested in point [4]. > >1. Name of the library would be better changed. > Hearing it for the first time I suspected > something like variant on std::endl. I agree, especially as it also works for input as well. >2. The first part of documentation should > be what is purpose of the library. okay. > I guess in this case it is debugging > and testing support, 100% cases. It can also be used for additional stuff (see Techniques section for examples). As a demonstration, if you implement localization within your program by providing a std::map< std::string, std::string > locale; where you do something like: std::cout << locale[ "usage" ]; you can use my library to read it in. I understand you can use the serialization library to do this, but you can control the formatting in my library, allowing: english.loc "welcome" = "My World" "" spanish.loc "wecome" = "Mi Tierra" "" german.loc "wecome" = "Meine Welt" "" I am not sure how feasible it is to do something like this in the serialization library. >4. There seems to be significant overlap > with Boost.Serialization (I suspect > outfm doesn't handle cyclic > structures). outfmt does not support cyclic structures. > It may or may not be possible > to implement outfm functionality > with special archive. > > Was this considered? Is it possible to control the formatting for the same type to produce different results? For example: std::pair< std::pair< int, char >, std::pair< int, char > > p; std::cout << io::formatob( p, io::pairfmt ( io::pairfmt().format( " | " ), io::pairfmt().format( "{ ", " }", " : " ) ) ).format( "<: ", " :>" ); // output: <: ( 5 | a ), { 5 : a } :> >5. To support debugging I would like to see > many more features: It is possible to create your own format object and delimeter formatter classes to extend the libraries functionality, so some of what you suggest can be done that way. I am thinking of extending the library to support function objects as delimeter types, thus expanding the possible uses of the library. I am also planning on supporting character escaping to better support string in/output as well as allowing HTML/XML character escapers. You can produce simple HTML/XML output using format(), for example: std::cout << io::formatob( vec, io::containerfmt ( io::wrappedfmt().format( "<li>", "</li>" ) ).format( "<ol>", "</ol>" ) ); // output: <ol><li>a</li><li>b</li><li>c</li></ol> Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

tiny review iostreams library
by Jan Christiaan van Winkel 12 Sep '04

12 Sep '04

Hello, I have been asked by Jonathan D. Turkanis to take a look at his iostreams library that is currently in review for inclusion in Boost. He asked me because I presented a paper at ACCU in 2003 about adding a filtering capability to iostreams aloing with a very convenient notation to sting filters together using the vertical bar (|) as is done in UNIX. I had very little time to do a decent review (busy working on the Netherlands Unix Users Group's conference about system administration and network engineering - see www.sane.nl it will be great!), but I think I have a good impression of the structure. 1) The library fills in some (for me) much needed gaps in the standard iostreams library. Especially being able to use a (pre-opened) filedescriptor is important to me (since attach() was not included in the standard). 2) The filtering idea I have great feelings about - I wouldn't have written an article about that kind of thing if I didn't like the idea ;-) I would like the vertical vbar (akin to UNIX'pipe notiation) were also available, but I heard that Jonathan has already worked on that. In general, I think his approach is far, far better, more evolved and complete that my own try, that was only meant as a proof of concept. What I would like: a good user-level manual. The documentation is filled with quite some standardeze (and rightly so - it should be exact!). But users may not see the full strength of the library if they are not introduced to the library using some user-oriented documentation. So, my conclusion: I hope the submission of the library to boost is succesfull - the library would be most helpfull. JC -- ___ __ ____________________________________________________________________ |/ \ Jan Christiaan van Winkel Tel: +31 24 3527252 jc(a)ATComputing.nl | AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands __/ \__/ __________ http://www.ATComputing.nl/image/midfotos/jc.jpg _________

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >Here are some general comments: >---------------------------------- > >0. I think the library should be put in the directory >"boost/output_format" >I hate cryptic names. Or "boost/ioformat" since it also has input capabilities :). There was talk when I was developing the library about moving it into the "boost/io" directory, but that seems to be getting a little crowded ;) >1. In this example > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > >why does the change of braces change "," to ":" ? It doesn't! This was a typeo. (Fixed in my documents, will commit post-review). >2. In this example > > int a[] = { 5, 4, 3, 2, 1 }; > std::cout << boost::io::formatob( boost::io::range( a, a + 5 )); > std::cin >> boost::io::formatob( boost::io::range( a, a + 5 )); > // output: [ 5, 4, 3, 2, 1 ] > >it might be good to support a range version with the posibility to > >1. throw if there is too few elements >2. default initialize if there is too few elements You mean when reading in the input? The default behaviour is to set the input stream fail bit, so you can check that. >3. cryptic name: formatob.hpp && formatobex; should be format_object and >whatever the latter really means I was going for ease of typing :). maybe boost::io::format/boost::io::formatex. The latter allows you to control the delimeter type being used, so you can do: std::wout << boost::io::formatobex< const wchar_t * >( v ).format( " : " ); >4. given std::cout << boost::io::formatobex< std::string >( v ); > > maybe std::string should be a default argument? I was thinking here about performance. The default type is const char * which should be fairly flexible without providing compy penalties. >5. A lot of boost::io::range() can be replaced with one Taking a Single >Pass >Range You mean from your Boost.Range library? This is something that I am considering, but don't know enough of the library to do this yet. >6. STL IO: It is not obvious how insertion is done? With push_back or by >overwriting elements? The container is cleared and insert is used to insert the elements into the container. >7. why is it necessary with > boost::io::formatob( boost::io::range( a, a + 5 )); > could we not just say > boost::io::range( a, a + 5 ); Because the boost::io::range_t class (created by boost::io::range) does not provide input/output functionality. It is a holder for a range [first, second) so that boost::io::formatob can process it. This is if you either specify a std::pair (boost::io::formatob treats this as a 2-ary type and not a range holder) or a (first, last) pair of values (since boost::io::formatob accepts a single object). It could be possible to make boost::io::range return a boost::io::formatob_t type (and thus allow the above), but when I previously used seperate constructs, it interfered with the type/format deduction mechanism. >8. It should be possible to say > > vector<int> v = ...; > cout << v; > >without the format_ob() if I include stl.hpp, ie, overloads for all >standard >types. Yup. This will provide the default formatting ("[ a, b, c ]" in this case). If you need alternate formatting, you need to use boost::io::formatob. >9. I would prefer basicfmt_t to be basic_format_type or perhaps >basic_fmt_type >if the "fmt" shorthand is used consistently etc. That is, all the cryptic > concatenation should be removed. That would make things fairly long-winded. For example: std::pair < std::pair< int, std::vector< char > >, std::list< std::complex< float > > > mct; std::cout << boost::io::format_object( mct, boost::io::pair_format ( boost::io::pair_format ( boost::io::basic_format(), boost::io::container_format() ), boost::io::container_format( boost::io::nary_format()) ) ); compared to: std::cout << boost::io::formatob( mct, boost::io::pairfmt ( boost::io::pairfmt( boost::io::basicfmt(), boost::io::containerfmt()), boost::io::containerfmt( boost::io::naryfmt()) ) ); >And now my review comments. > >| When doing the formal review, please answer the following questions: >| >| 1. What is your evaluation of the design? > >seems ok. I'm a little irritated about too cryptic names, concatenation and >_t >types. Basically, the "_t" types indicate the implementation type of a given construct. For example, the boost::io::formatob function creates an instance of the boost::io::formatob_t class. With regards to names, I am intending on changing FormatTraits to DelimeterTraits and possibly a few others. I am not sure what you mean by concatenation. >| 2. What is your evaluation of the implementation? > >haven't looked. > >| 3. What is your evaluation of the documentation? > >good, although I miss return-types and template paramaters and some >synopsises >with better overview. >For example, what does boost::io::formatobex< DelimeterType >( const T & ob >); >return? Maybe it doesn't matter, but >then it should say <i>Implementation-defined</i>boost::io::formatobex< >DelimeterType >( const T & ob ); etc. Okay, I will bear that in mind. FYI, the above function returns: formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >::type::outputter > ! My rationale for not supplying the return types was to not consume more space and not confuse readers. Marking them *implementation defined* would be a good idea. >| And most important, >| 8. 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. > >yes. I think all issues can be dealt with quite easy for a post-review. Great. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Re: [boost] [Config] Re: serializing a hash_map (tweaks for gcc-3.3.4/libstdc++-v3)
by Robert Ramey 12 Sep '04

12 Sep '04

troy d.straszheim wrote: >>> I have a patched stdlibcpp3.hpp and serialization/hash_map.hpp if >>> somebody wants 'em... >> >> Yes, please post them as attachments, and put [Config] in your >> subject line. >Here they are. I figure there is a "best practice" I'm missing (that >#ifdef __GLIBCPP__ looks out of place to me in hash_map) if so clue me >in for future reference. Also that <ext/hash_map> might very well >apply for __GLIBCXX__ as well, dunno, I made the minimum change to fix >my platform... Shouldn't there be similar set of changes for hash_set as well? Robert Ramey

1 0

RE: [boost] Re: Re: Formal review of "Output Formatters"librarybeginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote >| Thorsten Ottosen wrote: >|The default behaviour is to set the >| input stream fail bit, so you can check that. > >Ok, I guess that goes in hand with the bahavior of the standard library >(although I prefer throw by default). > >could syntax like > >std::cin >> io::throw_on_error() >> io::formatob( ... ) >std::cin >> io::default_init_rest() >> io::formatob( ... ) > >be supported too.? Possibly. I'd need to look into this. >| >3. cryptic name: formatob.hpp && formatobex; should be format_object and >| >whatever the latter really means >| >| I was going for ease of typing :). maybe >| boost::io::format/boost::io::formatex. The latter allows you to control >the >| delimeter type being used, so you can do: > >yeah, what does "ex" mean? "extended". A better name is probably needed and should be consistent throughout (i.e. for boost::io::wrappedfmtex, etc.) The problem is how to keep close to the original so that you know what it does and also tells you that this variant controls the delimeter type, since you can't reuse the original name due to overload resolution issues. >| I was thinking here about performance. The default type is const char * >| which should be fairly flexible without providing compy penalties. > >seems reasonable...just mention this stuff in the docs. It is (in a round-about way). I have fixed in my local docs to say: "This uses const char * as its delimeter storage type." >| >5. A lot of boost::io::range() can be replaced with one Taking a Single >| >Pass >| >Range >| >| You mean from your Boost.Range library? This is something that I am >| considering, but don't know enough of the library to do this yet. > >Ok, basically you can replace > >foo( std::pair<iterator,iterator> ); >foo( T (&array)[sz] ); >foo( const standard_container& ) >foo( builtin-strings ); > >with one function taking a Range > >foo( const Range& ); Great! I will replace boost::io::range and boost::io::range_t with this post-review. >| >6. STL IO: It is not obvious how insertion is done? With push_back or by >| >overwriting elements? >| >| The container is cleared and insert is used to insert the elements into >the >| container. > >ok, a small comment about it would be good. Done in local docs. >| >7. why is it necessary with >| > boost::io::formatob( boost::io::range( a, a + 5 )); >| > could we not just say >| > boost::io::range( a, a + 5 ); >| >| Because the boost::io::range_t class (created by boost::io::range) does >not >| provide input/output functionality. It is a holder for a range [first, >| second) so that boost::io::formatob can process it. This is if you either >| specify a std::pair (boost::io::formatob treats this as a 2-ary type and >not >| a range holder) or a (first, last) pair of values (since >boost::io::formatob >| accepts a single object). > >hm...it seems to me that boost.range has all you need: > >class iterator_range or class sub_range + >function make_iterator_range( a, a + 5 ); > >I could probably benefit you code to use this instead (unless I'm >overlooking >something). Nope. I'll update post-review. >| >9. I would prefer basicfmt_t to be basic_format_type or perhaps >| >basic_fmt_type >| >if the "fmt" shorthand is used consistently etc. That is, all the >cryptic >| > concatenation should be removed. >| >| That would make things fairly long-winded. For example: >| [snip] > >yeah, I know, but at least say pair_fmt instead of pairfmt etc. Yes. This is better. >| I am not sure what you mean by concatenation. > >the contraction of X_fmt to Xfmt. Okay. I'll look at revising the affected names. >| Okay, I will bear that in mind. FYI, the above function returns: >| formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >| >::type::outputter > >| ! My rationale for not supplying the return types was to not consume more >| space and not confuse readers. Marking them *implementation defined* >would >| be a good idea. > >yeah, that would be sufficient. Great. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

1 0