On Mon, 13 Nov 2006, Paul Eggert wrote: > "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).
I'll look up my exact specs and respond to this later. > In all cases I did "make check" twice, once to bring as much as > possible into RAM, the second time for the actual timing. I also discarded the first run, but I didn't think to mention it. > >> 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. My experience for that last point has not been the same. > Things might be > different if we were exporting this interface to the world, I suppose. If it's good for the world, then I'm not quite sure why it shouldn't good for Bison developers... especially given that Bison developers readily come and go from the world. In other words, the barrier to entry for Bison internals is rather high (in my recent experience), and clean internal API's should improve that situation I think. Don't misunderstand me. I do not plan to go on a crusade to restyle Bison internals all at once (or ever most likely). I usually only try to restyle code that I have some other reason to touch... and sometimes not even then. > 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++. Do you have anything specific in mind? > 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. Ok, thanks, I'll try.
