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?
>  I am not that familiar with using iterator_facade
>  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
> >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
> 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
> >and/or partial ordering. Cause it look way too complex and
> 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
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?
Do not abbreviate.
> >11. Need for all this hierarchies:
> 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.
> >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
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
You presented library call *Output* formatter. Why do we talk about input at
> >14. list_object -> formatter_t inheritance look wrong.
> Where is IS A
> list_object *isa* formatter_t *isa* openclose_formatter_t
> using the new design:
> list_object *isa* sequence_decorators_t *isa*
> wrapper_decorators_t *hasa*
List_object IS A formatter ????
Something really worng with naming here.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk