jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) (03/08/90)
A short while ago, I attempted to post an article in which I decried Eiffel's
lack of a class which would allow me to store and retrieve objects from
memory, rather than to/from a file. I am attempting to integrate Eiffel with
a networking utility, and I want to be able to store arbitrary Eiffel objects
in a structure which can be passed between machines. The STORABLE class does
what I want to do, but it can only read or write to disk, not to a buffer in
memory. So rather than wait for ISE to add a store_to_memory function to the
STORABLE class, I am implementing my own, by hacking the code in the _store.c
and _retrieve.c files in /usr/licensed/Eiffel/files. And it's going well,
except for this latest problem:
I want to pass the address of a particular (integer) field of an object to
a C routine I've written. The class looks something like this:
class STORED_OBJECT
...
feature
hash_value: INTEGER;
hash is
external
hash_object(current_obj: ANY, hash_val: ANY)
language "C"
do
hash_object(Current, @hash)
end
end -- stored_object
The idea is that I want my hash_object function to be able to reference
the hash field of my Current object. But when I try to compile this code,
it gives me:
Pass 1 on class stored_object
...
C-compiling stored_object
"stored_object.c": line 125: unacceptable operand of &
es: C-compilation canceled
Why is this? Changing the declaration of hash_val from ANY to INTEGER doesn't
help. Removing the @ sign in the call to hash_object removes the error, so
I _know_ there's something wrong with the compiler or with my understanding
of the @ operator.
Can someone at ISE or elsewhere please help me out? I will have to hack
around this in an ugly way if I don't get an answer. Thanks for any advice.
Rob Jellinghaus | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_summer@shiva.trl.oz (Mark Summerfield) (03/09/90)
In article <18296@cs.yale.edu< jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) writes:
<
<I want to pass the address of a particular (integer) field of an object to
<a C routine I've written. The class looks something like this:
<
<class STORED_OBJECT
< ...
<feature
< hash_value: INTEGER;
< hash is
< external
< hash_object(current_obj: ANY, hash_val: ANY)
< language "C"
< do
< hash_object(Current, @hash)
< end
<end -- stored_object
<
<Pass 1 on class stored_object
<...
<C-compiling stored_object
<"stored_object.c": line 125: unacceptable operand of &
<es: C-compilation canceled
<
<Why is this?
I had exactly the same problem- I think it's a bug in the compiler which
causes it to generate incorrect C code. The C, if you look at it,
attempts to cast an object structure to type integer (presumably the
integer is the first field of the object structure), and then pass a
pointer to the C routine (in this case hash_object). ie the C code
is (effectively- it doesn't look exactly like this!)
hash_object( ... , & (int) object )
I don't believe this is a legal C construct. The correct code would
be:
hash_object( ... , (int *) &object )
If this is a bug (and I'm prepared to be corrected, because I would
like to make it work too!), you may have to work around it by actually
editing the C files (yuk, blechh) but this is utterly impractical if
you've got more than one or two instances of this, and completely defeats
the purpose of the nice incremental build system ISE have provided us
with.
If you find a better solution, let me know.
Mark Summerfield, Telecom Research Laboratories, Australia.yost@esquire.UUCP (David A. Yost) (03/10/90)
In article <18296@cs.yale.edu> jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) writes: >A short while ago, I attempted to post an article in which I decried Eiffel's >lack of a class which would allow me to store and retrieve objects from >memory, rather than to/from a file. I am attempting to integrate Eiffel with >a networking utility, and I want to be able to store arbitrary Eiffel objects >in a structure which can be passed between machines. The STORABLE class does >what I want to do, but it can only read or write to disk, not to a buffer in >memory. A while back, I proposed that there should be "CHAR_PRODUCER" and "CHAR_CONSUMER" deferred classes, and that all I/O should go through them. So, for instance, the FILE class would inherit from these, and all the getint, putint, etc. features of FILE would be taken out and put where they belong, in their respective classes (INTEGER, for getint putint), where they would take a CHAR_PRODUCER or CHAR_CONSUMER argument as appropriate. (I think the FILE class needs a lot of changes.) This suggestion bears on your point, I think. It implies that STORABLE should have only one store feature instead of the present 3 variants, one each for storing to a filename, a FILE object, or a unix file descriptor. This one store feature would simply take a CHAR_CONSUMER argument. It seems clear to me that STRING should inherit from CHAR_CONSUMER, and either it or another similar class that acts only as an array of CHARACTERs (without all the text manipulation features) should be capable of absorbing your entire STORABLE (growing dynamically as necessary). The retrieve features of STORABLE should be changed along similar lines. --dave yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different.