- Boost - lists.boost.org

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

22 Sep '04

Rozental, Gennadiy wrote: >Here some more details: > > > 1. What is your evaluation of the design? > >Library trying to solve in fact trivial problem. Would it be presented as >trivial function > >Template<typename C> >Foo( C const& c, std::string open, std::string close, std::string sep ); > >I may understand it. This would mean that you would duplicate code for rendreing container types. Also, you are missing special formatting, e.g. wrapping open/close values around elements, e.g.: std::cout << formatob( vec, containerfmt( wrappedfmt().format( "<e>", "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> the indentation functionality that Volodya has expressed an interest in, and position-based output, e.g.: [0] John, [1] James, [2] Marina Also, the library should be usable on a standard stream. This is one of the key design aims. Can you do: std::cout << Foo( vec, "< ", " >", " :: " ); ? This requires returning an object that has << implemented. The mechanism for this is outlined in the standard by using *manipulators*. Thus, you would need that class to defer processing to the Foo function if you want to use your approach. >As to presented design - I see it as unnecessary complicated. And in many >cases simply incorrect. >Library does not follow standard practice as to wide char support. I am addressing these issues. See my other discussions for details. >Interfaces seem confusing and error prone. >Decoration model seems too simple to warrant so much trouble as reusable >library. Maybe more powerful/flexible solution should be considered. I have been reshaping the decoration model and have commented on it elsewhere. > > 2. What is your evaluation of the implementation? > >In most part I either don't understand or don't like it. IMO simple task >library trying to solve shouldn't require that much code. Simple >overloading >base solution should've done the trick. This does not allow for flexibility to add indenting, wrapped data, etc. > > 4. What is your evaluation of the potential usefulness of the library? > >Now to the most important: why would I ever want to use library like this? > >We have already: >std::ostream >boost::format >boost::serailization > >In what scenario I would use this library? But you can't do: std::vector< int > vec; std::cout << vec; // oops! no operator << defined for vectors. >I most definitely wouldn't want to repeat all this formatting every time I >need to output my vector. If you want [ a, b, c, d ] style output, you don't. The extra machinery is used to customize this. Also, you can save a format object, e.g.: // old style containerfmt_t< char, pairfmt_t< char > > myformat = containerfmt( pairfmt().format( " = " )).format( "<< ", " >>" ); std::cout << formatob( vec, myformat ); // << ( a = 5 ), ( b = 7 ), ... >> std::cout << formatob( lst, myformat ); // << ( i = 2.132 ), ( j = 3.14159 ), ... >> std::cin >> formatob( vec, myformat ); >If I write output operation rarely - I would use explicit loop -it's more >flexible anyway. Depends what you are outputting. If the type contains nested containers, it can be more complex. >I wouldn't use this library for filtering - we will have iostreams library >for that (If I am not mistaken). This library does not provide filtering capabilities. What I was saying is that if you want to pretty print the data, it might be worth using Jonathan's library. >I wouldn't use this library for XML printing - why would I want to mention >tag name twice? You can use a wrapper format object: std::cout << formatob( vec, containerfmt( wrappedfmt().format( "<e>", "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] OutFmt library implementation questions
by Reece Dunn 22 Sep '04

22 Sep '04

Rozental, Gennadiy wrote: > > >4. How does this all machinery will work with wchar_t? > > > > std::wcout << formatob( vec, containerfmtex< wchar_t * > > >()).format( L" - > > " ); > > > > Use the ex< DelimiterType > variant on the innermost construct. > >This is inacceptable and does not follow standard practice. The new version templates that are templatized on character type are also templatized on the format object that they use (to render their elements). This means that in order to provide c/w-style interface, you need: template< typename CharT, class ElementRenderer = basic_default< CharT > > class basic_container{ ... }; basic_container< char > ccontainer(){ return( basic_container< char >()); } basic_container< char, ElementRenderer > ccontainer( const ElementRenderer & er ){ return( basic_container< char >( er )); } basic_container< wchar_t > wcontainer(){ return( basic_container< wchar_t >()); } basic_container< wchar_t, ElementRenderer > wcontainer( const ElementRenderer & er ){ return( basic_container< wchar_t >( er )); } // what about custom character type (e.g. unicode?) basic_container< char > my_format = ccontainer().decorate( " : " ); std::cout << io::object( vec, my_format ); std::cout << io::object( vec, ccontainer().decorate( "< ", " >" )); > > This is a VC 6.x workaround. > >But you don't list this compiler amoung supported. At the moment there are a few problems with it. I am looking to resolve these if possible. > > >6. Why the same entity you sometime call format_type and sometime > > >DelimeterType? > > > > format_type is the typedefed version (should be delimiter_type) and > > DelimiterType is the template parameter. > >So is it delimeter type or forat type - it can't be both. delimiter type. In the new version it is char_type since the decorators (formatters in the review implementation) now take a CharT parameter instead of the storage type. > > >7. What deducer is supposed to deduce? I couldn't get > > through all the > > >details, but couldn't the same be achieved using partial > > specialization > > >and/or partial ordering. Cause it look way too complex and > > unnecessary. > > > > The deduction mechanism is used to evaluate what type T is > > (e.g. std::pair< > > char, int >), what format object is needed to render it > > (including nested > > format objects) and to construct the appropriate format object. > > > > It could be possible to use partial specialization, but the > > type traits are > > used elsewhere to redirect formatting behaviour (e.g. when > > reading in a > > container do diffreent things if it is a sequential, > > associative or set > > container). > >IMO all that you needed is function overloading. I don't see a place for >all >these deduce/trats staff. Consider the pair format object (pair renderer): how do you render each pair type. Using function overloading, you would have: class basic_pair { public: OutStream & write( OutStream & os, const std::pair< T1, T2 > & p ){ ... } OutStream & write( OutStream & os, const boost::compact_pair< T1, T2 > & p ){ ... } OutStream & write( OutStream & os, const std::complex< T > & p ){ ... } OutStream & write( OutStream & os, const boost::math::interval< T > & p ){ ... } }; But this would add dependencies on those libraries. Also, it is not extensible: how do you add support for boost::rational< T >, for instance? Using the deduction mechanism, I implement the output using boost::io::detail::getval< n >( pair_type ). Input is more complex because you need to distinguish between types that you can get the elements separately (e.g. std::pair) and types that you need to set both values together (e.g. boost::math::rational): the former uses refval< n >( type ) and the latter uses assignval( type, first, second ). How would function overloading solve this? (Note, function overloading is used for getval, refval and assignval). For containers, you need to use a different function/function arguments to insert an element depending on whether the container is sequential, associative or a set. My library provides a description of the types that it can render (e.g. separable pairs, 4-ary types, associative containers) without saying what these types are. The stl and boost directories in my library then tell my library that a std::vector is a sequential container. My library then knows how to handle a std::vector. Doing this, I can separate the dependencies on external libraries and allow it to be extended to support other sequential containers, pairs, etc. > > >11. Need for all this hierarchies: > > >Formatter->formater_t->openclose_formatter_t > > > > This is to ensure that the return type of 'format' in Formatter > > [FormatObject] is Formatter and not openclose_formatter_t. Thus: > > formatob( vec, containerfmt().format( " / " )); > > will work as intended without overriding 'format' in > > containerfmt_t (created > > by containerfmt()) to return the correct type. > > > > >openclose_formatter->openclose_formatter_t > > > > > >are completely unclear. Explanations presented in docs does not help > > >since format methods seems to be returning *this anyway. > > > > They return: > > *static_cast< ReturnType * >( this ) > > to allow 'format' to return the correct type when inherited > > in the format > > objects. > >Formatob_t::format return *this. You did not answer my question. I still >believe it's all unnecessary. formatob_t::format returns *this because the FormatObject (Renderer) that it inherits returns a value of type FormatObject. Thus, if you didn't have these overloads, then: std::cout << formatob( vec ).format( " + " ); would not work, since it will try to output a containerfmt() type. > > >Why couldn't we just use something trivial like > > > > > >template<char Ch> > > >struct formatter > > >{ > > > std::basic_string<Ch> m_open; > > > std::basic_string<Ch> m_close; > > > std::basic_string<Ch> m_sep; > > >}; > > > > > >Is beyond me. If any member is empty it means it missing. > > > > This is the direction I am going in the development version. The only > > difference is that I am using io::decoration< CharT, int id > > > instead of > > std::basic_string< CharT >. The decoration class uses > > std::basic_string to > > store the values, while providing support for looking up the > > default value > > on a stream and an external function for checking for a match > > on an input > > stream. > >You presented library call *Output* formatter. Why do we talk about input >at >all. The *output* designation is a "legacy" from before the library supported input facilities. People expressed an interest in inputting as well, so I added it; output stuck. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

Spirit on Intel 8.0/Linux
by Aleksey Gurtovoy 22 Sep '04

22 Sep '04

Folks, Is this a known problem that somebody can comment on (from http://tinyurl.com/5hhne) icc: error: Fatal error in /opt/intel_cc_80/bin/mcpcom, terminated by segmentation violation compilation aborted for ../libs/spirit/test/./ast_calc_tests.cpp (code 1) . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -g -O0 -I"../bin/boost/libs/spirit/test" -I"../libs/spirit" -I".." -I"/usr/include" -I"/boost/head-regression/boost" -o "../bin/boost/libs/spirit/test/ast_calc_tests.test/intel-8.0-linux/debug/ast_calc_tests.o" "../libs/spirit/test/./ast_calc_tests.cpp" ? This obviously looks like a compiler issue, but before I mark it up as such I'd like to hear if anybody has to say anything on it. There are more Spirit tests failing in a similar manner on this configuration -- see http://tinyurl.com/5dtbz. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] outputformatters - using just one decorator string
by Reece Dunn 22 Sep '04

22 Sep '04

John Torjo wrote: >Hi Reece, > >This just popped into my head. A lot of confusion seems to come from how >you pass decorators. What I'm trying to say is that it can be very >difficult to get the decorator strings right (especially for more complex >things like XML) from the first time. > >I would suggest every formatter takes only one string which parses and >finds all decorators itself. >Each formatter will have one or more escape sequences which it uses to find >the decorators. > >Something like: > >// in this case, '%' is used for identifying an element >// '*' is to mean "leave default" (don't change) > >std::vector<int> v; >// equivalent to your "[ ", ", ", " ]" >std::cout << formatob(v, "[ %, % ]"); This looks good :) On the implementation side it would require splitting the string into the 2/3 components and constructing the decorators accordingly. Maybe defining an "extract_decorators" function internally, so wrapper_decorators and sequence_decorators can process this internally. How about: std::cout << io::object( v )( "[ %, % ]" ); I am sure this would be feasible. >// eq. to "<< ", " | ", " >>" >std::cout << formatob(v, "<< % | % >>"); > >// set only open/close decorators >std::cout << formatob(v, "<< %*% >>"); Here, you would need special handling of string == "*". This should also be implementable. >// sets only the separator >std::cout << formatob(v, "*% | %*"); > >// for pair - you have "%1" and "%2" >std::vector< std::pair<int,long> > vp; >// write XML >std::cout << formatob(vp, > containerfmt("<elem> % </elem><elem> % </elem>", > pairfrt("<int>%1</int><long>%2</long>"))); Here, you don't need %1 and %2. You just do: "<int>%</int><long>%</long>". >How's that? In terms of implementability, I don't see a problem. The two issues I have are: [1] What are the performance penalties for this? [2] What if you want '%' or '*' in your format string, e.g. "[ a * b * c ]"? You would thus need to implement some sort of escaping capability. NOTE: This could sit along side using the 'decorate' function and Volodya's idea for expressions, e.g.: io::object( v, "<<" + fmt::container( fmt::pair()( "<a>%</a>%" )) + " >>" ).decorate( " : " ); // output: << <a>2.75</a>1 : <a>3.14159</a>7 >> Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Support Requests-1032391 ] bug in boost using STLport?
by SourceForge.net 22 Sep '04

22 Sep '04

Support Requests item #1032391, was opened at 2004-09-22 07:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1032391&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andi (andreasfuchs) Assigned to: Nobody/Anonymous (nobody) Summary: bug in boost using STLport? Initial Comment: Hi, I want to run a project under Visual .Net 2003 using boost1.31.0 and STLport. Compilation and linking runs perfect. But if I start the excecutable the debugger terminates with an "Access violation" error at at line 97 in _construct.h of STLport. I posted this message to the STLport forum. They told me that this could also be a bug in the boost library because before this error occurs some boost functions are called. So are there any known bugs using boost together with STLport und Visual .Net? Any help would be appreciated. Thanks a lot Andi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1032391&group_… ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] OutFrmt lib design questions
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> >Here some question I've got while reading submitted library. > > > >1. What is an advantage if using this library for scalar types (vs. > >defining > >operator<<) > > Do you mean for things like int, Person, etc. If that is the > case, the > default behaviour of the library is to delegate output of > these types to > operator<<, so it doesn't do much. However, with support for a > fmt::serialize formatter that calls 'serialize' instead of > <<, you can > register a particular class as being serializable so my type > deduction > system knows to associate instances of that type with > fmt::serialize, so you > can then do: > > // new design > std::cout << io::object( my_serializable_object ) << '\n'; > std::cout << io::object( vec_of_serializable_objects ) << > '\n'; // [ ..., > ..., ... ] I don't really interested in another serialization library. We already have one. > The advantage of using this for things like std::complex or > boost::math::quaternion that already supply << and >> > operators is if you > want to have control over how a type is rendered, e.g.: > > // new design > std::cout << io::object( complex_val ).decorate( "", "", " + i" ) > << " = " << io::object( complex_val ).decorate( "( ", " > )" ) << '\n'; And you believe that I will keep repeating this code every time I need to print my complex value? > >2. If primary target is collection formatting wouldn't it be > better to > >name library "collection formats something"? > > This is a good idea. The name is from when the library just > had output > support, thus the "outfmt" directory in the sandbox. I am > thinking about > moving to a "formatter" directory. What do other people think? > > >3. If there is a way to assign format to collection/type combination > >permanently (through global operator <<), why would I want > to do it in > >every instance of output operation? > > Do you mean: > std::vector< int > vec; > std::cout << "vector = " << vec << '\n'; // [1] > std::cout << "vector = " << io::formatob( vec ) << '\n'; // [2] > > using [1] vs using [2]? If so, these are the same, but the > second allows you > to customize the decoration around the sequence, for example: > std::cout << io::formatob( vec ).format( " : " ); // [ 1 : > 2 : 3 : 4 ] No my question was Is there a way to assign custom (meaning different from one you selected) decoration permanently. > >4. What is an advantage of using this library to assign format to > >collection/type combination permanently vs. explicit implementation > >(using FOREACH construct for example) > > Using a foreach construct you would need to hand-code the surrounding > decoration, e.g.: > > // output: { a + b + c } > std::cout << "{ "; > foreach( char ch : vec ) > { > std::cout << ch; > if( !atend ) std::cout << " + "; > } > std::cout << " }"; > > vs: > > std::cout << io::formatob( vec ).format( "{ ", " }", " + " ); // output: > { a + b + c } > > If you have a nested construct, such as int tictactoe[ 3 ][ 3 > ], std::list< > std::list< float > > or math::matrix4x4< float > then > outputting/inputting > it manually would be more complex, whereas my library has all > the machinery > to handle this simply. Yeah. But I do it only once. And using foreach is way more flexible. I don't believe your library bring any advantage in this scenario. > >5. Why do we need boost::io::range? Couldn't we use boost::range > >instead? > > I suppose it would be possible to use > boost::range::make_iterator_range > instead. The only thing I have against this is its length. Consider: > > // new design > using boost::range::make_iterator_range; > namespace range = boost::range; > namespace io = boost::io; > > std::cout << io::object( range::make_iterator_range( i, i > + 7 )); // [1] > std::cout << io::object( make_iterator_range( i, i + 7 )); // [2] > std::cout << io::object( io::range( i, i + 7 )); // [3] > > If only you could alias functions, e.g.: > namespace io{ alias range = boost::range::make_iterator_range; } IMO you shouldn't introduce yet another range notion. > >6. In a formatter usage how would I guess what is what? > > boost::io::formatter< char * > fmt( "\ ", " /", " | " ); > > boost::io::formatob( vec, > boost::io::containerfmt()).format( fmt ); > > I have revised the names, so that is now: > namespace fmt = boost::io::format; > > io::sequence_decorators< char > seq( "\\ ", " /", " | " ); > io::object( vec, fmt::container()).decorate( seq ); IMO it's really bad idea to introduce interfaces that change meaning depend on number of arguments of the same type. Moreover it easy to confuse one with another. Your interface: ( str1, str2, str3 ) - open, close, separator ( str1, str2 ) - open, close ( str1 ) - separator Now If I do not use your library on everyday basis, And look on invocation of first function - how would I now what is what. There should be something that tell explicitly - here is open/close brackets, here is separator. > >7. Who come format calls order dependent? > > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt > >).format( > >" : " ); > > format( fmt ) is called first, then format( " : " ). Thus, > you will have "\ > a : b : c /" as the formatting. You did not answer the question. I believe that interface is incorrect if it order dependent > >9. Let say I print vector<char>. Is there way to print it > like this: { > >'a', 'b', 0x01, ' ' } Actually I did not want '' around hex value - intent was to print array in c++ format. > Yes. You need to provide a wrappedfmt() format object. For example: > > formatob( vec, containerfmt( wrappedfmt().format( "'", "'" > ))).format( "{ > ", " }" ); > // output: { 'a', 'b', 'c' } So this wouldn't wark for me since I do not want '' around some of the values. > With the 0x01 character, special treatment needs to be > applied. You will > need to supply a custom format object to see if the character > is printable, > e.g.: > [your 20 lines solution skipped] IMO In this scenario your library doesn't stand a comparison with handcrafted solution. > > Regards, > Reece Gennadiy.

2 2

Patch for program_options<mingw>
by Janusz Piwowarski 22 Sep '04

22 Sep '04

Hello I'm attaching patch for program_options which fixes known problem with wstring in mingw. Regards, Janusz

2 2

RE: [boost] immutable string
by Ben Hutchings 22 Sep '04

22 Sep '04

Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > I've been working on a small library - an immutable C++ string. Now > it is in usable state and has been put in use in a couple of real > projects. > Although it needs further polishing, I would like to know is there > any interest in such a library? Great stuff. I certainly think it would be useful to have a light- weight string. > Here is the link: http://conststring.sourceforge.net/ There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC? [*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about. Ben.

3 4

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

22 Sep '04

Vladimir Prus wrote: >Reece Dunn wrote: > > > You can explicitally state where/how new lines and indentation are going > > to be within my library by adding them to the open/close/separator > > formatting (see output-3D.cpp for an example). > >Yes, but I'd rather write > > os << v > >and have the right formatting, even if 'v' is a vector of something, which >has vector members, and the vector element type has another vector member, >and so on... This would further complicate the implementation of the library. To do what you want would require something similar to the Cascading Style Sheet proposal to maintain the default values for each format object type. This would be more complex for it to handle std::vector and std::list separately, but it may be possible to use the ID returned by type traits (differentiating sequential, associative and set containers). >The wrapping is indeed a separate issue. What I was asking is support of >indenting in your library. For example, the output such as >[snip] >Yes, except that I'd want "multiline" to act recursively, so if I print >vector of maps, the result will look like: >[ > { > a: 1 > b: 2 > } > { > c: 3 > } >] > >or using a different syntax. It would be possible to make use of a state object: a state object is an object that is rendered before or after an element is rendered. The implementation of this using the review version would be complex, but possible. I was considering adding pre+post support for a state object. Another idea is to implement an "event object" that gets called at the various stages of output. e.g.: Event::handler( before_decorator( io::open_decorator_id )); os << open; Event::handler( after_decorator( io::open_decorator_id )); // ... I'll need to think about this. >I'd suggest that you at least try to make top-level functions non-inline. >That would reduce the code size for application which use your library -- >I've had this experience both with program_options and function. For a >single library, it's probably not a huge difference, but if all libraries >use inline less liberaly, the code size of C++ apps would be lower. ok. noted. > >>I might be missing something, but the mechanism for getting the type of > >>formatter from a type to be output seems too complex. First, the > >>type_deducer.hpp file is used, and 'select' computes a 'category'. Then > >>format_deducer.hpp takes the category, and again uses 'select' to obtain > >>the real type of formatter. Why the type_deducer.hpp is needed? > >... > > > template<> struct deduce_type< io::seq_container_type > > > { > > template< typename CharT, typename T > > > struct type_from > > { > > typedef typename T::value_type value_type; > > typedef typename get_deducer< CharT, value_type >::type > > value_deducer; > > > > typedef container_t > > < CharT, typename value_deducer::format_object > format_object; > > > > static format_object deduce( const T & ) > > { > > return( format_object( value_deducer::deduce( >value_type()))); > >Does this expects the T::value_type is DefaultConstructible? IIRC, >containers only require that objects be CopyConstructible and Assignable. Don't std::list implementations work like: struct list_node { T value; list_node * prev, next; }; typedef list_node list_node_block[ 100 ]; // ... so T needs to be DefaultConstructible. I'll need to consult C++98 to be sure. > > } > >Still, I don't understand the need for integer type category. Can't you >have > > 'deduce_sequence_type' > 'deduce_pair_type' > >and so on, and use 'select' to map a type directly into those classes, not >into integer? Then I would need to do: select < is_std_vector< T >, deduce_sequence_type, is_std_list< T >, deduce_sequence_type, ... > This would not allow you to add a new container type into the mechanism without obtrusively altering the code. Also, there is a limit to the number of template parameters on select. The present system simplifies this by mapping to a category. (This also allows you to write more generic code, for example fmt::pair is implemented using these categories to work out how the pair type is constructed and fmt::container uses it to provide different behaviour for sequential, associative and set-based containers). In the new type deduction system, I map type --> type to extract a format object type, e.g. assoc_container_type to seq_container_type. This allows you to only provide one template overload. This system is more extensible than the review version (using select). > >> "providing an extensible framework that sits" > >> > >>How it's extensible? I see only one section about extending and it's >just > >>one paragraph long > > > > I really need to add more documentation regarding this. The idea is that > > you can: > > > > * add your own decorators (delimiters in the review docs) to support >more > > complex types (e.g. trees and graphs). > >That's interesting. Can you explain? You can write a class similar to [openclose_]formatter to add your own decorator type, e.g.: // new style template< typename CharT > struct binary_tree_decorators { decoration< CharT, 3 > left; decoration< CharT, 4 > right; // ... }; where 3 and 4 are the decorator IDs for the left and right decorations. You can then make use of this in a tree format object, e.g.: os << tree.left << left << tree.value << right << tree.right; resulting in something like: 1 <-- 2 --> 3 combining this with fmt::wrapper: [[1] <-- 2 --> [3] ] <-- 4 --> [[] <-- 5 --> [[6] <-- 7 --> []]] This is just an example. Consideration would need to be given to how the data is nested and how it interacts with the rest of the library. > > Underlying type is: typeid(ob).name(). > >Sorry, that's the name of type ;-) Maybe you just mean "according to its >type?" (also note "its", not "it's"). The "underlying" implies there's some >another type, besides 'T'. yes! >Maybe, you can use something like: > > "The 'object' function can only output a container, so to output a range > of iterators you need to make a container from it using io::range". "output a container": the argument is not necessarily a container (e.g. std::pair). How about: "The 'object' function can only output an object of type T (it cannot output ranges declared using two arguments), so to output a range of iterators you need to make a container-like object from it using io::range". >The original sentence sounds like the format is something external to >openclose_formatter, and the class is just a proxy which allows to set it. It is a holder for several decorations (e.g. open/close or open/close/separator), allowing you to set more than one of these and - in the discussion of using expressions - dealing with the evaluation of one of these expressions, e.g.: fmt::container() / " + " > >>The code block before > >>this comment defines two classes openclose_formatter_t and > >>openclose_formatter. Is this a typo, or you really have two classes? > > > > This is not a typo. The _t variants take a template parameter that > > contains the return value of the 'format' ('decorate') functions. This >is > > so that: > > std::cout << io::object( vec, fmt::container().decorate( " | " )); > > works properly. > >Why don't 'decorate' return the same type as 'fmt::container()'? Because they are implemented in wrapper_decorators_t [review version: openclose_formatter_t] and sequence_decorators_t [formatter_t]. To return the same type as fmt::container() would require implementing the 'decorate' function in the fmt::basic_container class (i.e. implementing 5 or 6 functions). You would need to do this for all the other format objects, including the ones that the user writes, so why do this? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: Formal review of "Output Formatters" library beginstoday
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

Hi, I would like to start with resolution. I vote NOT to accept this submission. Here some more details: > 1. What is your evaluation of the design? Library trying to solve in fact trivial problem. Would it be presented as trivial function Template<typename C> Foo( C const& c, std::string open, std::string close, std::string sep ); I may understand it. As to presented design - I see it as unnecessary complicated. And in many cases simply incorrect. Library does not follow standard practice as to wide char support. Interfaces seem confusing and error prone. Decoration model seems too simple to warrant so much trouble as reusable library. Maybe more powerful/flexible solution should be considered. > 2. What is your evaluation of the implementation? In most part I either don't understand or don't like it. IMO simple task library trying to solve shouldn't require that much code. Simple overloading base solution should've done the trick. > 3. What is your evaluation of the documentation? Did not get to this stage. > 4. What is your evaluation of the potential usefulness of the library? Now to the most important: why would I ever want to use library like this? We have already: std::ostream boost::format boost::serailization In what scenario I would use this library? I most definitely wouldn't want to repeat all this formatting every time I need to output my vector. If I write output operation rarely - I would use explicit loop -it's more flexible anyway. If I write output operation frequently - I would separate in function and here again would use explicit loop for the same reasons. If I write many output functions like above - I would write wrapper function like in 1. And it will work for most collections. I wouldn't use this library for filtering - we will have iostreams library for that (If I am not mistaken). I wouldn't use this library for XML printing - why would I want to mention tag name twice? Anybody? > 5. Did you try to use the library? Did not get to this stage. > 6. How much effort did you put into your evaluation? A quick In-depth study. > 7. Are you knowledgeable about the problem domain? That's the main issue - I do not see problem domain. Regards, Gennadiy.

2 1