Hi Misha, 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 > 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 [...] > 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). 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. Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
