> Why reinvent the wheel and not reuse existing code, which is much more > flexible (and _you_ are the one, who stresses flexibility) and better > fits into the task to solve.
Even with my limited knowledge of Spirit, still I do not believe I duplicate Spirit functionality in any way. What I define are the skeletons for different parsing logics. One could choose what parser (interpreter in my terms) to use to do a real job. > I like the way Valodiya solves this: a > clear, streamlined but extensible library with a simple but powerful > interface. I would appreciate your comments on both submissions. Doesn't my solution is "clear, streamlined with a simple but powerful interface. > If I need cla parsing (quite simple or more elabourated - as > in your geometry sample), I can write my own parsers and make them fit > into the picture seemless without any headache. So you could with my framework. > I do not > expect from the > cla framework to do the parsing for me, I do. Why should I repeat string->type interpretation in every program that use cla framework. Another reason is that IMO it's more C++ like solution to work with typed parameters and arguments. Would I work in perl I prefer strings. Also typed parameters allowed me to perform additional validation on whether value could be interpreted as target type. > it should return strings > associated with keys (which are strings too) from different locations > (cla, cfg file, registry etc.). That's all. I do provide an ability to return string results of course if you prefer that. > > Just my 2c worth. > Regards Hartmut > Gennadiy. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
