[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: encapsulating code properties
From: |
Paul Eggert |
Subject: |
Re: encapsulating code properties |
Date: |
Mon, 13 Nov 2006 09:38:42 -0800 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
"Joel E. Denny" <address@hidden> 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.
- encapsulating code properties, Joel E. Denny, 2006/11/11
- Re: encapsulating code properties, Paul Eggert, 2006/11/11
- Re: encapsulating code properties, Joel E. Denny, 2006/11/12
- Re: encapsulating code properties, Paul Eggert, 2006/11/12
- Re: encapsulating code properties, Joel E. Denny, 2006/11/12
- Re: encapsulating code properties,
Paul Eggert <=
- Re: encapsulating code properties, Joel E. Denny, 2006/11/13
- Re: encapsulating code properties, Paul Eggert, 2006/11/13
- Re: encapsulating code properties, Joel E. Denny, 2006/11/13
- Re: encapsulating code properties, Joel E. Denny, 2006/11/13
Re: encapsulating code properties, Joel E. Denny, 2006/11/13