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.