jacob navia said:
Jordan Abel a écrit :
Ahhh living in the past.
Those never ending historical trivia that seem to have so
much success here.
Some of us find historical trivia interesting. Apart from being
interesting for their own sake, they can be helpful to understand why
the C language is the way it is, warts and all.
I tried to start a discussion based in the interface concept
but it went completely down the drain.
Yes, well, that happens sometimes. We're not obligated to discuss
whatever you find interesting, any more than you're obligated to
discuss what we find interesting.
Having said that, your idea for interfaces
<
http://groups.google.com/group/comp.lang.c/msg/857ea8e70333c6c5?hl=en&fwc=1>
does look at least moderately interesting. To summarize:
struct ArrayList;
struct ArrayListInterface {
int (*GetCount)(struct ArrayList *AL);
int (*IsReadOnly)(struct ArrayList *AL);
int (*SetReadOnly)(struct ArrayList *AL, int flag);
int (*Push)(struct ArrayList *AL, void *str);
};
struct ArrayList {
struct ArrayListInterface *lpVtbl;
size_t count;
void **contents;
size_t capacity;
unsigned int flags;
size_t ElementSize;
};
(This isn't identical to the code you posted; I've fixed some syntax
errors and dropped the typedefs in favor of using struct tags
directly.)
One difficulty with this approach, as compared to the equivalent in a
language like C++ that support OO directly, is that you have to
manually build and initialize the function table yourself; the
compiler won't do it for you. If you forget to do this, Bad Things
Happen; for example:
struct ArrayList obj;
int count = obj.lpVtbl->GetCount();
invokes undefined behavior. But that's not a fatal flaw; it's easy
enough to declare an object that provides a default initial value:
const struct ArrayListInterface ArrayListInterfaceDefault = {
...
};
struct ArrayList ArrayListDefault = {
&ArrayListInterfaceDefault,
0,
...
}
and then:
struct ArrayList obj = ArrayListDefault;
int count = obj.lpVtbl->GetCount();
will consistently give you 0.
I think this kind of thing is often overkill if you don't actually
need more than one implementation of, say, the GetCount() function for
your type. Plain old type and function declarations, with no attempt
to encapsulate the functions in the types, is very often perfectly
adequate. But when it isn't, this seems like a reasonable approach.
(Please note that I'm discussing your idea because I find the idea
itself interesting, not because I'm influenced by your complaints
about other things being trivial.)
The 8086, the PDP7, that is MUCH more fun. The only answers
I got pointed to some triviality. The discussion here never
gets to any substantive discussion about modern software construction.
Maybe you should try comp.programming.
