Re: subroutine stack and C machine model

On 2009-10-26, jacob navia <jacob@xxxxxxxxxx> wrote:
Maybe you should study C better. Interface is a common concept in C (as it
is in all programming languages). I presented an interface proposal
for several containers here and its implementation in C. You have the
right (of course) to disagree with that interface proposal, you can tell
me it is wrong because many reasons, but you can't deny the fact that
it is an interface!

I used the term to refer to the common feature in OO languages of allowing
a single interface specification to be used by multiple different objects,
giving them compatibility despite having different types. This allows,
for instance, both list objects and array objects to implement the shared
interface "container", and be used interchangeably by code which relies on
the "container" interface.

This is not something that C really supports. Without the ability for objects
providing substantially different APIs to share a common subset, a "container"
is not very useful; you may want an array, and you may want a list, but if
you want one you probably don't need the other. It's only in languages that
let you express to the compiler/interpreter that there's a shared interface
that it's useful. IMHO.

Denying the fact that C has (as all programming languages) the
interface concept shows that you either did not give much thought
to what you were writing, or that you fail completely to grasp concepts
that go beyond churning some code!

That's entirely possible.

However. It seems to me that there are two likely possibilities:
1. Someone who's been using C for something over twenty years, and uses
both "API" and "ABI" correctly and in context, and is a fluent speaker of
English, does not realize that the ability to describe the set of calls
available in a given context could be called an "interface".
2. The term "interface" has another, more-specific meaning, to which that
person was referring.

Do you have a guess as to which one of these is more likely?

You say that you would "rather pick abstractions with some awareness
of the specific circumstance in which I'm using them" without noticing
that precisely abstractions should be mostly independent of the exact
place where they are used, and that is why they are useful ABSTRACTIONS!

I do actually know about this. The thing is, there is such a thing as "too
abstract to serve my purposes". Certainly, I can implement just about
any data storage with the interface:

int add_to_object(void *object, void *data, void *key);
void *retrieve_from_object(void *object, void *key);

And then I just have to do:

int sum = 0;
for (int i = 0; i < 10; ++i) {
int *p;
p = retrieve_from_object(my_array, &i);
if (p) {
sum += *p;
}
}

.... but this might actually suit my needs less well than a more specific
implementation, shocking though it may seem!

Yes, there is no inheritance in C, but you do not need any inheritance
to describe an interface to an abstract container. I fail to see
any hierarchy in those containers, at most a grouping that can be useful
and an INTERFACE that allows for maximum flexibility.

The normal way this would be done would be to have a generic "container"
interface, then more-specific "array" and "list" interfaces, which are
indicated in some way to be supersets of container, such that code which
works on "containers" can work on both arrays and lists. C really can't
express this well, and without it, "container" is a pretty poor choice
for abstraction, while "array" and "list" are very good choices for
abstractions.

I hope I misunderstood you, and that you can clarify your position.

I don't know about the clarification. I have had issues trying to communicate
with you in the past; for instance, when I pointed out that there was no
obvious reason to imagine a performance penalty for indirect calls, you
pointed at research on the performance penalty for virtual functions in C++,
which is a VERY different application than mere "calls through function
pointers".

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@xxxxxxxxx
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
.

Quantcast