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.