"Joel E. Denny" <[EMAIL PROTECTED]> writes: > My results disagree with yours.
Could be our development environments and/or CPUs, I suppose. I'm using a Debian stable environment (x86), but with GCC 4.1.1 installed. My CPU is a 2.4 GHz Pentium 4 with 512 KiB cache, a 533 MHz FSB, and 512 MiB DRAM (ECC). In all cases I did "make check" twice, once to bring as much as possible into RAM, the second time for the actual timing. >> action_location_set >> (rules[ruleno].action, >> code_props_location_get (something_something_something_get (p)); > > I see no problem with the latter case. I do, unfortunately. It's too wordy for what should be a simple assignment "rules[ruleno.action].location = p->something.location". There are some software-engineering advantages to the wordiness, but some real disadvantages too. In a small, self-contained project like Bison the disadvantages tend to dominate more. Things might be different if we were exporting this interface to the world, I suppose. Also, if we could use C++, we could eliminate a lot of the wordiness as well. But I wouldn't favor making that transition. There are much better choices than C++. >> I have less strong feelings about this, partly because I don't use >> Doxygen. > > I'm not sure what you're saying. Are you willing to accept the "\c"? > Are you suggesting we drop Doxygen from Bison altogether? The \c gets in the way of reading, but on further thought if you're willing to maintain it I guess I'll live with it. Please try to minimize its use, though; if you can think of a different way of wording that uses fewer instances of \c, that would be nice.
