Boost logo

Boost :

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-09-20 17:08:58


Hi,

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.

2. Why doesn't insert_iterator is implemented using iterator_facade?
3. Why do you need 2 different functions containerfmtex and containerfmt?
4. How does this all machinery will work with wchar_t?
5. Why do you need static_cast< const base_type * > to cast to the base type
in container.hpp?
6. Why the same entity you sometime call format_type and sometime
DelimeterType?
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.
8. Why class formatter, formatter_t is defined in namespace io, while it
reside among details headers?
9. What is RT2 stands for?
10. detail/formatter.hpp refer to openclose_formatter_t, but does not
include no headers.
11. Need for all this hierarchies:
Formatter->formater_t->openclose_formatter_t
openclose_formatter->openclose_formatter_t

are completely unclear. Explanations presented in docs does not help since
format methods seems to be returning *this anyway. 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.
12. select and switch templates seems useful. Why doesn't MPL provide these?
13. Doesn't MPL provide eq_int, lt_int?
13. struct selector needs to be PP generated
14. list_object -> formatter_t inheritance look wrong. Where is IS A
relationship?
15. You couldn't do this: typename InputStream::char_type ch = '\0';

I think It all for now.

Please comment.

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk