Boost logo

Boost :

From: Misha Bergal (mbergal_at_[hidden])
Date: 2003-05-28 13:47:32


"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:basnho$kmt$1_at_main.gmane.org...
> Hi Gennadiy,
>
> Gennadiy Rozental wrote:
> > Looking on class cmdline one will be puzzled: what king of design if
> > follow? Is it container of iterator? Seems like both. If I remember
> > correctly this is how some ancient pre-standard, or RW containers were
> > implemented. I don't believe this is kind of design we want to promote.
>
> Alas, this comment seems non-constructive for me. I don't think that
> the question is what kind of design should be promoted. What are the
> problems with the current design? Can you list some interesting things
that
> would be possible if config_file were an iterator? What would be its
> value_type? And what will operator++ do on error?
>
Gennadiy's comment might seem to be non-constructive. But I believe it has
some merit to it.

When I look at the Doxygen class reference cmdline I want to understand
it's design quickly
and unambigously Some other people might do it differently, but for me the
only way to do it quickly and unambigiously is
to recognize there the patterns I've seen before and know how to operate
with.

The smaller the number of those patterns (concepts) - the easier it is to
the users. When I (and probably Gennadiy) looked at cmdline parser I could
not quickly recognize any of the patterns we already know there. This design
might be completely justified, but still it is kind of struggle for me to
understand it.

Saying "I don't believe this is kind of design we want to promote" I would
mean "1. Introducing the new pattern (concept) is costly for the users 2. I
believe it is important goal of Boost to build on or extend the existing
patterns(concepts) used in the standard library or other parts of Boost
where possible. This would significantly lower the users' costs"

I consider Gennadiy's question to be legitimate(but may be not perfectly
stated).

Misha


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