RE: [boost] OutFmt library implementation questions

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-09-21 11:52:58

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

Compring to output operations?
 

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

This is inacceptable and does not follow standard practice.
 
> >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.

But you don't list this compiler amoung supported.
 
> >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.

So is it delimeter type or forat type - it can't be both.
 
> >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).

IMO all that you needed is function overloading. I don't see a place for all
these deduce/trats staff.

 
> >9. What is RT2 stands for?
> 
> ReturnType2.

Do not abbreviate.
 
> >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.

Formatob_t::format return *this. You did not answer my question. I still
believe it's all unnecessary.

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

You presented library call *Output* formatter. Why do we talk about input at
all.

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

List_object IS A  formatter ????
Something really worng with naming here.
 
 
> Regards,
> Reece

Gennadiy.