New subject: OutFmt library implementation questions

22 Sep 2004

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

RE: [boost] OutFmt library implementation questions

Rozental, Gennadiy

John Torjo

Gennadiy Rozental

Reece Dunn

Gennadiy Rozental

John Torjo

tags

participants (1)