- Boost - lists.boost.org

RE: [boost] OutFrmt lib design questions
by Reece Dunn 21 Sep '04

21 Sep '04

Rozental, Gennadiy wrote: >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'; // [ ..., ..., ... ] 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'; >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 ] >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. >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; } >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 ); >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. >8. If I got vector<vector<int> >. How do I supply separators for both >internal and external vectors? You apply the 'format' function to containerfmt(). For example: boost::io::formatob( vec, containerfmt( containerfmt().format( " : " )).format( " + " )); // output: [ [ a : b : c ] + [ x : y : z ] + ... ] >9. Let say I print vector<char>. Is there way to print it like this: { 'a', >'b', '0x01', ' ' } Yes. You need to provide a wrappedfmt() format object. For example: formatob( vec, containerfmt( wrappedfmt().format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } 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.: class char_escape { public: typedef void traits_type; typedef const char * format_type; typedef boost::io::seq_type< -1 > formatter_type; public: template< typename CharT, typename TraitsT > static std::basic_ostream< CharT, TraitsT > & write( std::basic_ostream< CharT, TraitsT > & os, CharT value ) const { if( isprintable( value )) return( os << value ); return( os << "0x" << int( value )); } }; formatob( vec, containerfmt( wrappedfmt( char_escape()).format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

Outdated GCC versions checks with BOOST_TESTED_AT()
by Jonathan Wakely 21 Sep '04

21 Sep '04

There's an out-of-date workaround in dynamic_bitset/config.hpp, which tests the compiler version to see if a GCC bug is still present. The bug is still present in GCC 3.4, so BOOST_TESTED_AT should test 30400. Also, boost/variant/detail/move.hpp contains this: #if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP) \ || BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(2)) Should that be changed? IIUC that means that GCC 3.x uses the workaround for non-ADL compilers. Since GCC 3.x has pretty good (not perfect) ADL, and since the BOOST_TESTED_AT is outdated, that test should be changed. Finally, boost/iterator/detail/config_def.hpp tests # if BOOST_WORKAROUND(__GNUC__, == 2) && BOOST_WORKAROUND(__GNUC_MINOR__, BOOST_TESTED_AT(95)) \ This looks outdated - there will be no more GCC 2.x releases and I would be surprised if vendor-specific releases such as RedHat's GCC 2.96 fixed that issue, but GCC 3 probably did. I can check this assumption if someone can provide a testcase but I would expect the test can be changed to simply: # if BOOST_WORKAROUND(__GNUC__, == 2) \ since it applies to all known version of GCC 2.x, and there will not be any more 2.x releases. The attached patches make the first two changes. I have left the third, since it doesn't affect GCC 3.x so is doing no harm, and because I'm not sure the bug has been fixed. jon -- I listen a lot and talk less. You can't learn anything when you're talking. - Bing Crosby

1 0

Boost.Python/vc6 regressions
by David Abrahams 21 Sep '04

21 Sep '04

Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. Here is the error output: ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** ***************************************************************************** -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

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

21 Sep '04

Rozental, Gennadiy wrote: >Here some implementation questions I've got: > >1. Why does the library brake const correctness. FWIV I could write: > > const vector<int>& v = ...; > > std::cin >> io::formatob( v ); > > and it would compile without questions. I'll try to resolve this issue. >2. Why doesn't insert_iterator is implemented using iterator_facade? [1] I am not that familiar with using iterator_facade [2] Is it worth the abstraction penalties? >3. Why do you need 2 different functions containerfmtex and containerfmt? This was so that older compilers (e.g. VC 7.0) could resolve the arguments correctly. The new implementation just uses the single function name. >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. >5. Why do you need static_cast< const base_type * > to cast to the base >type >in container.hpp? This is a VC 6.x workaround. >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. >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). >8. Why class formatter, formatter_t is defined in namespace io, while it >reside among details headers? It is included in the <boost/outfmt/formatter.hpp> header. In the new version, these are in an "impl" directory, i.e. are part of the implementation and should not be included directly. >9. What is RT2 stands for? ReturnType2. >10. detail/formatter.hpp refer to openclose_formatter_t, but does not >include no headers. See question [8]. >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. >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. >12. select and switch templates seems useful. Why doesn't MPL provide >these? I don't know. Dave? >13. Doesn't MPL provide eq_int, lt_int? I think so. I am not an MPL expert. I should really fix this. >13. struct selector needs to be PP generated Again, I am not a PP expert. I will look into this. >14. list_object -> formatter_t inheritance look wrong. Where is IS A >relationship? list_object *isa* formatter_t *isa* openclose_formatter_t using the new design: list_object *isa* sequence_decorators_t *isa* wrapper_decorators_t *hasa* decoration >15. You couldn't do this: typename InputStream::char_type ch = '\0'; Since the new version takes template< typename CharT > across the board, this is now: CharT ch = CharT(); So I have fixed the problem. 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

Re: Lexical cast suggestion
by Martin Adrian 21 Sep '04

21 Sep '04

Sorry for not keeping the thread. Got some strange errors from when using followup in gmane >I think that it's not such a big problem. If you want to use locales, then >your application should start with: > > std::locale::global(std::locale("")); > >after that, I think lexical_cast will use the default user's locale. Or you >can replace "" above with something else that your application wants. The >only problem is that it's not possible to use several locales in one >application. For program_options, it's not very important. > >Why do you need to specify locales for call to 'lexical_cast'? There are two different cases here. The first one is when you are communicating with the user (e.g. via a GUI). You will then ofcourse use the system locale to format output and parse input. Since c++ defaults to the "C" locale you need to add the line you mention above to get streams, sorting etc to work properly. But, it is also common to do things in an application that doesn't follow the system globale like parsing and writing xml or csv files, generating SQL statements etc. (program options might fall into theis category as well) For the two cases above you need to use different locales. Since lexical_cast doesn't allow you to specify which locale to use it can only be used for one of the cases above. The current implementation uses the global locale which basicly means that it should only be used for communication with the user. Since there seem to be a strong opinion against specifiying locale for lexical_cast I'm hoping that the documentation is updated to warn about lexical_cast for other things than communicating with the user. I learned it myself the hard way. When it comes to program options the author has decided to use lexical_cast and the global locale to verify input. It might be a good choice but it means that you can't move configuration files between computers with different locales. Better documentation might be sufficient here as well but there might also be other problems (like space as thousand separators on integers).

4 6

RE: [boost] Re: platform specific structures
by Ben Hutchings 21 Sep '04

21 Sep '04

Matt Hurd <matt.hurd(a)gmail.com> wrote: > Alexander Terekhov <terekhov(a)web.de> wrote: > > > > Matt Hurd wrote: > > [...] > > > > >> But why is a concurrent-aware setter useful if its effects > > > > >> aren't visible to the other threads? > > > > > > > > > > In what way do you mean they not visible? > > > > > > > > > > Such aligned memory operations are guaranteed to be atomic on > > > > > ia32 at a system wide level AFAIK. > > > > > > > > On IA32, sure, but not on other architectures. > > > > > > Yup. Which gets back to the subject line... > > > > On IA32, > > > > - stores have release semantics (sink-load/store mbar for > > preceding loads/stores in the program order); > > > > - loads have acquire semantics (hoist-load/store mbar for > > subsequent loads/stores in the program order); > > > > - lock instructions have compound release and acquire semantics > > (fully fenced). > > > > See Plan9 story for an illustration of lockless stuff that > > needs store-load fence (compound sink-store and hoist-load mbar) > > on IA32. > > > > http://groups.google.com/groups?selm=414E9E40.A66D4F48%40web.de > > (Subject: std::msync) > > > > regards, > > alexander. > > Always insightful, thanks Alexander. However, I'm not talking about > guarantees of ordering or timing, just "eventual" visibility. If a change to a variable is not followed by what the compiler sees as a release then the change could perhaps be moved into a following critical section, resulting in deadlock. See the last paragraph of <http://groups.google.com/groups?selm=409A193B.7DD71861%40xemaps.com> (further up the thread Alexander pointed at). Note also that the compiler could also hoist the test of the control variable out of the loop if it can tell that nothing in that loop will modify the control variable. This seems to me to be a more likely problem. It is possible that "volatile" may help you to ensure visibility, but the semantics of volatile are implementation-dependent and not well specified. <snip> > By the way, when you say ia32 which architectures are you referring > to, as they have varied quite a bit on their capabilities from 386 to > P4 & Xeon? <snip> The ordering guarantees remain much the same though the atomicity guarantees have become stronger as the bus width increased from 16 bits (386SX) to 32 and 64 bits. Ben.

2 1

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

21 Sep '04

John Torjo wrote: >>>My real observation is that I see this as orthogonal to serialization and >>>that it should remain that way. I don't seen any real overlap now except >>>that there might be a couple of instances where either one might do. I >>>think even these would be rare cases. I would resist any idea to >>>intertwine these concepts. >> >>I'm lost. What are "these concepts"? What I propose is that the >>"serialize" >>method be usable by the outfmt library to generate more usable output. No >>other link between the two libraries is suggested. >> >I assume you suggest something like: >- if an object can be serialized, use that for output Is there a way to test if a class can be serialized. If that is the case, maybe it would be beneficial to add it into fmt::basic using MPL wizardry. I.e. can you do: mpl::if_< is_serializable< T >, ..., ... > ? >- if not, use default (operator<<) > >This seems ok to me. Reece? I was thinking of having a separate format object (fmt::serialize?) instead of complicating fmt::basic. You can then do: BOOST_IO_CLASSIFY( SerializableType, boost::io::serializable_type ) to add it into the type deduction mechanism, unless there is an is_serializable< T > trait. Alternatively, you would be able to explicitly designate to use 'serialize': io::object( people, fmt::container( fmt::serialize())); Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

1 0

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

21 Sep '04

Vladimir Prus wrote: >John Torjo wrote: > > > The FORMAL Review of "Output Formatter" library begins today, > > Sept 12, 2004. > >The primary case is debugging. I want to either output small vectors to >some >log/dump file (in which case the output will be small one-line), or output >some huge structures (vector<Function>, where Function has a lot of data). >In the latter case, the output should be multiline, with nice indentation, >or I won't understand anything. 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). As for more intelligent indentation, it is hard to know in advance if an object you are writing to the stream should be wrapped or not. This is where feeding it through Jonathan's library (via an indentation filter) would be useful. >A particularly interesting question is how the proposed library overlaps >with serialization. When outputting vector<Function> I'd prefer the content >of 'Function' to be outputted too, preferably by describing the members >with the 'serialize' method. The default behaviour for an unrecognised type is to output it directly to the stream so it will use the << operator associated with that type. If you want to use a particular method, such as 'serialize', then you will need to write your own format object that calls that function. > > 1. What is your evaluation of the design? > >There are some things I don't like. First, as many mentioned, the naming is >not optimal. For example: > > boost::io::formatob(v).format(" | "); The naming scheme for the various elements has undergone an overhaul. See my other posts for comments. From here on in, I will use the new naming, with: namespace io = boost::io; namespace fmt = boost::io::format; >or maybe even > > ("[" + io(v)/"," + "]") Cool! I shall look into trying to implement something like this. >It's desirable that the library support some multiline output style out of >the box, so that I could write: > > os << io::multiline(v) << ... Do you mean something like: std::cout << io::object( v ).decorate( "[\n ", "\n]", ",\n " ); resulting in: [ 1, 2, 3 ] > > 2. What is your evaluation of the implementation? > >There should be the <boost/outfmt.hpp> header, including everything else of >the library. ok >Some of the lines are longer than 80 characters (e.g. template header of >formatob_t has 111 characters). ok >Methods defined in the body of the class are implicitly inline, there's no >need to put the "inline" in front of them, as it's just one more word to >read. ok >I don't think defining methods in the class is a good idea -- this makes >the >class interface less obvious. I agree. I prefer to keep interface and implementation seperate, but MS VC (prior to 7.1) will choke on nested templates declared out of line, e.g.: template< typename T > struct foo { template< typename U > void bar(); template< typename U > void ok(){} }; template< typename T > template< typename U > // VC<=7.0 ==> error void foo< T >::bar(){} I also try to be consistent where possible, so don't tend to mix the two. >Why is the formatob_t necessary? It seems to work by delegating everything >to the underlying formatter. Can't the 'formatob' just return the >appropriate formatter? It's necessary because the format objects don't define << and it is necessary to keep a refererence to the object passed to it for formatting so that it can be accessed when inside the implementation of the << operator. >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? I have been working on improving this. There are 3 parts to the type deduction: [1] identifying the type and mapping it to its generic type (e.g. container, array, etc.) This is done by type_traits.hpp. [2] working out the formatter type that is needed to render this to the stream. In the review implementation this is done by format_deducer.hpp, using the information gathered by type_deducer.hpp to compute the nested structure (e.g. std::vector< std::pair< char, std::list< int > > >). [3] creating an instance of the format object. This is also done by format_deducer.hpp in the review version. In the version I am working on at the moment, I have a deduce_type< int > template that is used to simulate partial specialization (for compilers that don't support it). The int parameter is the format object category and is taken from type_traits.hpp (or your own value if you add a custom type and format object). The decude_type template contains template< typename CharT, typename T > struct type_from{ ... }; that has a format_object typedef and the method: static format_object deduce( const T & ); for constructing an instance of that format object. For example: 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()))); } }; }; > > 3. What is your evaluation of the documentation? > >The documentation leaves much to be desired. I'll walk though some of the >aspects (indented text is quote from the docs) I will attempt to address the issues you have raised. > "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). * add your own format objects to control the way the data is rendered, for example adding a format object to call the 'serialize' method on a class. * create state objects used by fmt::state to perform custom formatting (e.g. in the john-torjo.cpp example, a state object is used to render the position: { [0] Vladimir, [1] Terje, [2] John, [3] Dave, [4] Rene } ) * register a type with the type deduction system so it can be implicitly deduced, e.g.: BOOST_IO_CLASSIFY_TYPE( 2, boost::array, io::seq_container_type ); // ... boost::array< int, 5 > a; std::cout << io::object( a ); // output: [ 1, 2, 3, 4, 5 ] > boost::io::formatobex< DelimeterType >( const T & ob ); > > This will format ob according to it's underlying type. > >How is this different from using the 'formatob' function. What's >"underlying >type". Underlying type is: typeid(ob).name(). That is std::vector< int > will be formatted differently to std::pair< char, std::list< std::complex< float > >. >I'd also suggest >for formatobex use the "basic" prefix to indicate it's templated on the >character type. E.g. stlio and basic_stlio, or something like that. That is a good idea. Especially considering the revisions I am in the process of making. > If you need to specify a range or sub-range, boost::io::formatob will >not > recongnise it unless it is a container. > > boost::io::range( ForwardIterator first, ForwardIterator last ); > >This is more of a language problem. Range, by definition, is a pair (but >not >std::pair) of iterators. It's never a container. What I meant is that: std::cout << io::object( vec ); // [1] ok - know how to process containers std::cout << io::object( a, a + 5 ); // [2] oops! don't know how to handle ranges std::cout << io::object( io::range( a, a + 5 )); // [3] ok - range is now explicit The reason I don't allow variant 2 is because that would mess up argument resolution. >For a reference, the code examples are not necessary. For tutorial, >you don't need to list every overload, just mention that there are others. noted. > boost::io::openclose_formatter is a class that allows the user to >change > and access the format used for open and close delimeters > >Here we're definitely in the reference docs already, while I did not get an >overall picture yet. Then, what's "change and access the format". If the >format can be changed, it is stored somewhere. Where? It is stored inside the [openclose_]formatter object (wrapper_decorators and sequence_decorators in the new version). You can set the delimiters (decorators in the new version) using the various 'format' functions ('decorate') and get their values via open(), close() and separator() (used when implementing your own format objects). >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. >Do you mean that every FormatObject class should have this signature? Then, >the phrase about "FormatObject::write(os, fo.ob)" is not necessary. ok. Regards, Reece _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

2 1

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

21 Sep '04

Vladimir Prus wrote: >Reece Dunn wrote: > > > Vladimir Prus wrote: > >>There are some things I don't like. First, as many mentioned, the naming > >>is not optimal. > >>[snip] > >>or maybe even > >> > >> ("[" + io(v)/"," + "]") > >> > >>for nested formats, something like > >> > >> ("[" > >> + io::format( > >> "(" + io::format()/":" + ")" > >> )/"," > >> + > >> "]" > >> ) > >> > >>These are just ideas, though. > > > > In my development version, I now have this working! That is, you can do: > > > > std::cout << io::object > > ( > > std::make_pair( 'a', 5 ), > > "{ " + fmt::pair()/" == " + " }" > > ) << '\n'; // output: { a == 5 } > >Great. I wonder what others think? Personally, I really like the / >operator. >Probably that's because I've borrowed the idea from one parser generator >which allows to write: > > (literal / "," ) > >to mean a list of literals separated by ",". Sure. Another alternative would be: fmt::pair()[ " = " ] but this may be confusing WRT the standard behaviour of the [] operator. >The opening and closing braces look less clear for me now. Maybe, we can >use > > fmt::pair("{", "}")/" == " The problem with this is deducing that the parameters passed to fmt::pair or others are format objects (for formatting first and second data members) or delimiter strings or other arguments (e.g. DelimiterType or array length). This could possibly be done using MPL, but would further complicate the implementation. >or > > fmt::braces("{", "}") + fmt::pair()/" == " > >But I'm really really not sure. Suggestions are always welcome. fmt::braces is openclose_formatter in the review implementation (wrapper_decorators in the version I am currently working on). The problem with defining operator + for <open_close> + <open_close_separator> value holders is: how do you inherit values, for example: fmt::braces( "<< ", " >>" ) + fmt::pair( "{ ", " }" )/" == " is this: << a == b >> or: { a == b } This would be "<< a == b >>" in this instance, because fmt::pair will set the values and fmt::brace will cause them to be overrided. This is similar to this situation: "<< " + fmt::pair().decorate( "{ ", " }" )/" == " + " >>" Also, MW CodeWarrior 9.2 is complaining about the above: typedef boost::io::sequence_decorators<char> decorators; ### mwcc Compiler: # 122: = "<< " + decorators() / " :: "; # Error: ^ # illegal operands 'boost::io::sequence_decorators<char>' / 'const char *' I will need to investigate this further. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: Formal review of "Output Formatters" library begins today
by Robert Ramey 21 Sep '04

21 Sep '04

Vladimir Prus wrote: >A particularly interesting question is how the proposed library overlaps >with serialization. When outputting vector<Function> I'd prefer the content >of 'Function' to be outputted too, preferably by describing the members >with the 'serialize' method. And the question is if I can use outfmt >library, or have to use the serialization library? The serialization >library is pretty large, so, I'd like outfmt to be able to output UDT which >have 'serialize' defined. IMO, vector<some_UDT> is a very common case, >maybe even more common than vector<pair<int, int> >. If one had nothing else to do, he could make a derivation of one of the existing archives (e.g. text_archive) that would "annotate" the serialization. This might be useful for debugging or other purposes. On the other hand, I just use the xml_archive for that purpose now and its fine (although a little verbose). It also plays nice with XML browsing tools. So that's handy. My real observation is that I see this as orthogonal to serialization and that it should remain that way. I don't seen any real overlap now except that there might be a couple of instances where either one might do. I think even these would be rare cases. I would resist any idea to intertwine these concepts. Robert Ramey

3 3