Boost logo

Boost :

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-17 16:04:40


> 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.


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