- Boost - lists.boost.org

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

13 Sep '04

David Abrahams wrote: >John Torjo <john.lists(a)torjo.com> writes: > > > When doing the formal review, please answer the following questions: > > > > 1. What is your evaluation of the design? > >It seems to introduce a great deal syntactic noise: > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > > >I'd like to (at least) see rationale on why something cleaner wasn't >chosen. For example: > > namespace io = boost::io; > std::cout << io::sequence( vec ); > // output: [ 1, 2, 3 ] > > std::cout << io::sequence( vec, "{ ", " }" ); > // output: { 1 : 2 : 3 } There are two basic components: a delimeter holder (formatter/openclose_formatter) that contain the delimeters and control over them, and a format object that tells the library what type the object being formatted is. Your suggestion for placing the delimeter specifications in the type construction messes things up since you are combining two separate concepts. This would lead to many different function overloads (you'd need one for each variant). Also, the design would fail when adding new delimeters for things like trees and graphs. >In case it's not obvious, I don't like the name "formatob." Abbrevs >should generally be avoided, and frankly I don't know what 'ob' >stands for. Also "format" doesn't seem to add much semantically. "ob" stands for "object". I am willing to negotiate appropriate names. io::sequence seems reasonable enough. >I'm generally not a great fan of statefulness, but this also seems >like a reasonable thing to want: > > namespace io = boost::io; > std::cout << io::sequence_delimiters("{ ", " }"); > std::cout << io::sequence( vec ); > // output: { 1, 2, 3 } You can achieve something like this using: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec ).format( fmt ); If there are any better alternatives, I am willing to listen. >Library organization seems problematic. On one hand, I'd like to see >the io for individual boost types like octonion distributed across >their respective libraries (e.g. in boost/math/io.hpp). On the other >hand that will introduce an "apparent library dependency" that may not >be needed by some. The "apparent dependency" of this library on all >the others isn't very comforting, either. Perhaps some refactoring is >appropriate. I think this will be an issue no matter how it is implemented. Especially for the STL container types. The code has already been refactored so that each STL/Boost type registers its self in a separate file, so you can include them individually. It might be a good idea to have the Boost/complex types include just the type deduction mechanism code. This would reduce the file/library dependencies. >Another point: I'd like to see functionality for pretty-printing >sequences. It's very common to have sequences that are too long to >represent comfortably on one line. There are several strategies for >dealing with that, and it seems to me that to be *really* >indispensible, this library should help in that department. I don't know if additional support needs to be built into the framework, but you can implement your own format object that could perform pretty-printing functionality, e.g.: std::cout << io::sequence( vec, io::pretty_container()); It should also be possible to design character escapers/unescapers, allowing: std::cout << io::sequence( str, io::container_fmt( xml::char_escaper().format( "", "" )); >It might >also need ways to prevent infinite recursion in self-referential >sequences (consider sequences that embed ranges). Hmm. I am not sure how to implement this. Suggestions are welcome. >Where's I/O for tuples? I have not added tuple support yet. > > 3. What is your evaluation of the documentation? > >What little I saw of the tutorial documentation looked readable and >comprehensible. The lack of namespace aliases in the examples don't >help the library's case. I'd like to see more rationales. okay. >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. >The use of "implementation defined" in the documentation is >incorrect. To be correct, the Boost implementation would have to >define whatever it is. The appropriate term is "unspecified." okay. >I/O for existing Boost types such as rational<>: > > IMO the fact that we didn't have I/O for these is sort of > embarassing, but at the same time it's unclear to me that not > having inserters/extractors was a burden for anyone. I can't > recall a single post asking where these things were. I/O does exist for rational, octonion, interval and so forth. The headers in my library for boost components are there to tell my library what type of sequence a particular type is (e.g. rational<> is a pair type, octonion an n-ary type and std::list a container). This is so that my library knows how to format that type. > > 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. > >The lack of reference docs is a showstopper for me. okay. I'll look at getting doxygen up and running on my machine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 7

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

13 Sep '04

John Torjo wrote: >>>Well, I think my alternative is better if you want a stateful change, >>>since yours doesn't accomplish that. My suggestion is certainly >>>consistent with normal io manipulators. The point is to stream a >>>bunch of sequences without having to repeat the format part. >> >>I understand what you are saying and yes your version is neater. However, >>implementing something like this would have performance penalties (because >>you will need to create/store the preset values at run-time). > >The penalties are small. Anyway, using std::istream/ostream have penalties, >compared to using raw FILEs ;) This is true. >That said, in this case there shouldn't be many penalties. >Again, you can use >ios_base::pword and ios_base::iword for this. >It's an advanced technique, but I think it can prove very neat and >flexible. okay. >>It will also change the way all sequence constructs are rendered. (n-ary >>types have a different rendreing so won't be affected). As I understand, >>this is the desired effect. But then: > >You can make it possible to associate a fmt object with a delimeter object. > >Example: pairfmt() with openclose_formatter. >basicfmt() with formatter. Etc. That is basically what I do already: wrappedfmt() is associated with openclose_formatter; pairfmt() is associated with formatter (using default_nary_traits) containerfmt() is associated with formatter (using default_sequence_traits) etc. At the moment, default_nary_traits/default_sequence_traits provide the default strings to map to the specific type, e.g.: const char * default_nary_traits< const char * >::open_default(){ return( "( " ); } wchar_t default_nary_traits< wchar_t >::open_default(){ return( L"(" ); } std::string default_nary_traits< std::string >::open_default(){ return( std::string( "(" )); } so you can theoretically use any string type to store the default delimeter values. How do we do the equivalent with ios_base::pword/iword? openclose_formatter/formatter set their delimeter values to the values provided by the default traits object passed to them. You can then override these defaults by calling format(). How do you tell that the default has been overrided? One solution would be to use a null string as a default value. Then you can do class openclose_formatter { private: inline DelimeterType get_default_open() const { return ios_base::pword -> open(); // pseudocode } public: inline DelimeterType open() const { return( _open == null ? get_default_open() : _open ); } }; but this would complicate the access process for open(), close() and separator(), that in the current implementation simply return the data member. Also, what about string types such as std::string, QtString, CBStr and CString? What are their appropriate "null" values and how do you test that? I suppose you could have a resolve_default_values() function in the formatter class that is called when using FormatObject::read/write to reduce the resolution to a single pass, but what about when you save a formatter/format object, e.g.: io::formatter< const char * > fmt( " : " ); // oen/close use defaults std::cout << io::formatob( lst, io::containerfmt()).format( fmt ) // [1] << io::set_sequence_defaults( "< ", " >" ) // [2] << io::formatob( vec, io::containerfmt()).format( fmt ); // [3] [1] will resolve the default values used by fmt, [2] will change the defaults used and [3] will not be updated to reflect these changes, so you'd need the slower version. Alternatively, you can do this in FormatObject::read/write: DelimeterType separator_delim = separator(); while( first != last ) { // ... os << separator_delim; } >Then, you can store (default) delimeter objects within the stream. >Once you want to output/input something, it requires a specific delim >object. You'll somehow use ios_base::pword/iword to get a reference to that >object. The main questions are: [1] how do you store different DelimeterTypes in this mechanism? [2] how do you tell if the default is needed (see above)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

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

13 Sep '04

John Torjo wrote: >>2. The first part of documentation should >> be what is purpose of the library. >> >> I guess in this case it is debugging >> and testing support, 100% cases. > >Introduction: >"The Standard Template Library (STL) provides a mechanism for storing >collections of objects, but does not provide I/O support via streams. [...] > The outfmt library is an attempt to solve the problems outlined above, >providing an extensible framework [...]" > >So, what I gather is that it provides customizable I/O for >containers/ranges. Yes. >That said, I donot think its purpose is debugging/testing support 100% >cases. It does definitely support that, but you can do more - like, do some >pretty printing to file(s), std::cout, etc. Yes. >>5. To support debugging I would like to see >> many more features: >> >> - ability to wrap long lines in pretty way > >I guess this could be solved by IO streams lib ;) :) The problem with doing this during the output phase with my library is that you don't know in advance if outputting the next element will wrap around to the next line (and thus will need a new line inserting). Jonathan's library does indeed provide a solution for this. The example he gives does not support smart word-wrap facilities, but this can be done by writing to an internal buffer and outputting that up to the last space in the buffer, retaining the rest of the buffer until it wraps. >> - ability to generate HTML as output >> (+ ability to fold/unfold big data >> structures using Javascript). > >I assume this could be added in time... Reece? You can generate this now if what you are generating is regular, for example: <ol><li>a</li><li>b</li><li>c</li></ol> if you want an id or special position-based output, you can create a state object and use statefmt() like is done in libs/example/john-torjo.cpp to output: [0] John, [1] Jane, [2] Claire, [3] Mark for example: <ol><li id = "elem1">a</li><li id = "elem2">b</li><li id = "elem3">c</li></ol> Alternatively, you can output the data as XML and use XSL:T to generate the javascript/dynamic content. For example: std::list< std::pair< int, std::vector< char > > > data; std::cout << xml_signature << '\n' << xsl_stylesheet_signature << '\n' << '\n' << io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "<seq><e>", "</e></seq>", "</e><e>" ) ).format( "<pair>", "</pair>" ) ).format( "<seq>", "</seq>" ) ); output: <seq><pair><e>5</e><seq><e>a</e><e>b</e><e>c</e></seq></pair><pair><e>102</e><seq><e>x</e><e>y</e><e>z</e></seq></pair></seq> If you want it to be pretty, e.g.: <seq> <pair><e>5</e> <seq><e>a</e><e>b</e><e>c</e></seq> </pair> <pair><e>102</e> <seq><e>x</e><e>y</e><e>z</e></seq> </pair> </seq> You can specify this as: io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "\n <seq><e>", "</e></seq>", "</e><e>" ) ).format( "\n <pair>", "\n </pair>" ) ).format( "<seq>", "</seq>" ) ); Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

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: > > >>I'm generally not a great fan of statefulness, but this also seems > >>like a reasonable thing to want: > >> > >> namespace io = boost::io; > >> std::cout << io::sequence_delimiters("{ ", " }"); > >> std::cout << io::sequence( vec ); > >> // output: { 1, 2, 3 } > > > > You can achieve something like this using: > > > > io::formatter< const char * > fmt( "{ ", " }" ); > > std::cout << io::sequence( vec ).format( fmt ); > > > > If there are any better alternatives, I am willing to listen. > >Well, I think my alternative is better if you want a stateful change, >since yours doesn't accomplish that. My suggestion is certainly >consistent with normal io manipulators. The point is to stream a >bunch of sequences without having to repeat the format part. I understand what you are saying and yes your version is neater. However, implementing something like this would have performance penalties (because you will need to create/store the preset values at run-time). It will also change the way all sequence constructs are rendered. (n-ary types have a different rendreing so won't be affected). As I understand, this is the desired effect. But then: [1] how do you select sequence or n-ary formatting? [2] what about extending this to incorporate - for example - tree or string formatting? [3] how do you extend this to formatter types that have additional delimeters? [4] how do you know when to extract the default delimeter values from the stream? Adding a formatter as a parameter to io::sequence, etc. would further complicate function lookup. Perhapse if I had an is_format_object< T >::value trait I could use MPL wizardry to distinguish between format object and delimeter formatter, allowing: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec, fmt ); // output: { a, b, c } The problem with this is: what if you want to specify a format object and a delimeter formatter? This might work, but the implementation becomes more complex. Another idea would be to overload an operator like: std::cout << io::sequence( vec )( fmt ); // output: { a, b, c } or std::cout << io::sequence( vec )[ fmt ]; // output: { a, b, c } but this would further add to the confusion. If operator() was adopted, it would be possible to have that as a shorthand for format(). For example: std::cout << io::sequence( vec )( " | " ); // output: [ 1 | 2 | 3 ] Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Access to compiler options for all tests
by Stefan Slapeta 13 Sep '04

13 Sep '04

Would it be possible to provide the compiler options also for the regression tests that passed? They sometimes are interesting, too! Stefan

2 1

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