From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-29 00:27:23
Misha Bergal wrote:
>> 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
>> 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
> 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
In your presentation the concern is quite clear, and indeed legitimate. I'll
try to see if/how it can be changed to use more common patterns. The
problem I see, is that to convert it into iterator, or an model of
Generator concept, one would need to introduce special class for
value_type. And that class will be very artificial: almost nobody would
want to use it directly. And such classes are not good idea, IMO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk