Re: Naming typedefs
- From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
- Date: Mon, 03 Sep 2007 21:16:46 +0200
SM Ryan <wyrmwif@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
# struct item item;
Geeze. struct is an ancient hack to make a one pass compiler
possible.
Ah. And what precisely is that supposed to mean and for what
particular reason did you attach it to a line of text I have written
whose meaning you made untelligible to everyone by removing the parts
that talked about it?
The differing uses of structs and scalars are
mostly gone,
The only sensible interpretation of this is that you used to write C
in the past, but don't anymore. And that's a statement about you.
What is its purpose here?
but again stemming from an ancient compiler
problem that a scalar could be returned in the A register
while the stack pointer was adjusted behind it;
This sounds rather like an 'ancient' (if you like the term)
processor design, with a dedicated 'value register' named
'accumulator'.
returning a struct would require the caller allocate space
for the return value and (horror of horrors) for the function
to have waste precious cpu cycles copying the struct there
to slide it down the stack while popping.
Ehh ... yes ... returning a copy of some value requires that the
'original instance' of it is ... well ... copied to some location
allocated for that purpose. Returning a value which fits into a
register will usually use a registers and anything larger than that
needs to be copied to some main memory location. And compared to the
processor, main memory is really slow.
Remaining non-orthogonalities of structs and scalars are
due primarily to C inertia rather than underlying issues
of the hardware or twentieth century compiler technology.
Again, this is something which comes from CPU architecture and
not from 'compiler technology'.
As far as "but how am I supposed to know what the name
means without being told it's a struct," geeze again.
I didn't write that. I wrote that I have to remember what the text
does not contain explicitly.
It is not beyond the limits of human intellect to write
a tool that can collect references and definitions of
symbol and then feed that into an edittor that allows
you to move the mouse over a symbol and have the damn computer
tell you everything you need to know.
A lot of nonsense is well within the limits of human
intellect.
[...]
# important place, namely, the actually executed code. Finally, the
# typedef must be visible to be used and this will usually mean one has
# to include the header defining it into every other header (assuming
# self-contained headers are regarded as a good thing) which contains
# prototypes that use it, while a struct can just be declared as
I never realized writing header files was a major
intellectual challenge. It's an idiotic enterprise
because a compiler could actually extract interfaces itself
and allow them to be imported without so much work by the
programmer,
Viewed from a certain perspective, every aspect of writing code is an
idiotic enterprise which is best accomplished by some idiot (without
tie), so that 'more important people' can concentrate on 'more
important things'. This can even be generalized to any other type
of work: Pay some idiot to do it. Much more comfortable.
# available information on this is correct) is to just load everything I
# need into an Emacs buffer whenever I need it first and to rather
Maybe that's my problem. I don't use Emacs and the luxury of a single
buffer. I use XCode with all of its annoying multiple windows,
split windows, its control-click jump to definition, window frame
list with functions, #defines, typedefs, and all the rest of that
misery I must endure.
There's probably nothing conceivable in this respect that not at least
someone has already programmed in elisp fifteen years ago. But I must
confess that I am somewhat primitive in my tastes. For instance, I
really like ed, although it will certainly take some more years before
I have grown accustomed to it.
.
- Follow-Ups:
- Re: Naming typedefs
- From: SM Ryan
- Re: Naming typedefs
- References:
- Re: Naming typedefs
- From: Rainer Weikusat
- Re: Naming typedefs
- From: SM Ryan
- Re: Naming typedefs
- Prev by Date: Re: A question about typecasting in c
- Next by Date: Re: Naming typedefs
- Previous by thread: Re: Naming typedefs
- Next by thread: Re: Naming typedefs
- Index(es):
Relevant Pages
|
Loading