On Mon, 15 Jan 2001, Andre Poenitz wrote:
> > at the very least, without auto generation, you need :
> >
> > 1 place for the commandtag (commandtags.h)
> > 1 place for the invoke method (lyxfunc.C)
> > 1 place for the instantiation of the lyxfunc (LyXAction.C)
>
> What about nuking the commandtags and putting everything in a
> std::map<string, whatever>, where the index is the (first word of)
> the command?
>
> Comparing strings instead numbers should cost only a constant factor of
> time more than comparing enums, starting off from a very tiny amount.
> Morover, lookup in the map is O(ln n) compared to O(n) in the
> big case scwitch. So it shold not really be noticable.
you are forgetting the constants of the complexity equation. I bet the
compiler does a better job of the case() { } construct than it does of the
STL header code. (Of course, this argument is pointless w/o measurement to
back it up). And I don't see any real purpose to removing the array-based
approach ?
> The "big loss" is "type safety": We don't notice at compile time a
> misspelled command. OTOH at some time we might wish to dynamically
> extend lyx - say by a newly installed converter - without quitting the
> current work. In this case the infrastructure would be in place already.
would we really ever want to do this ? I don't see a good reason to lose
compile-time type safety, and this doesn't really help at all in terms of
readability of each function. Think about how we would add the author's
name and creation date, detailed usage instructions for the developer etc.
In my proposed scheme this all comes "for free" (with some nice doxygen
documentation to go along with it).
john
--
"Threads are for people who can't program state machines."
- Alan Cox
