RE: [boost] OutFmt library implementation questions

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-09-22 10:24:40

> > > Use the ex< DelimiterType > variant on the innermost construct.
> >
> >This is unacceptable 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). 

You keep repeating that you have some completely reworked version.
Well let's see it next time. Then I will be able to comment on it.

> > > >7. What deducer is supposed to deduce? I couldn't get
> >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? 

I am not sure I understand what you writing here. What I meant is something
trivial like this:

Template<typename C>
ContanerFormatter<C> Foo( C const& ); // this together with
ContanerFormatter is defined in pair general header
Template<...>
PairFormatter<..> Foo( pair<...> const& ); // this together with
PairFormatter is defined in pair specific header
Template<...>
RationalFormatter<..> Foo( pair<...> const& ); // this together with
RationalFormatter is defined in boost:: specific header

And so on.

Why wouldn't it work?

> 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.

If you need to handle input then in addition you would add 

Template<typename T>
VectorFormatter<T> Foo( std::vector<T> const& ); // this together with
VectorFormatter is defined in vector specific header

> 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.

I don't see ANY need for all this complex staff when simple
overloading/partial ordering will do the trick.

> 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.

Your code :
inline formatob_t &                  format( format_type s)
{
    FormatObject::format( s );
    return( *this );
}

formatob( vec ).format( " + " )

has the same type as 

formatob( vec )

What are you talking about? Why would you bother what FormatObject::format
is returning?
 
 
> Regards,
> Reece

Gennadiy.