- Boost - lists.boost.org

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

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