RE: [boost] OutFmt library implementation questions

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-21 07:51:24

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