tfb at tfeb.org
Thu Apr 15 10:11:22 UTC 2010
On 14 Apr 2010, at 22:50, Toomas Altosaar wrote:
> For example, the same as above: take the case where you wish to
> mirror all the non-LISP specific implementation data in your instance
> through an FFI to and from a framework. This version will give you a
> lower bound as to how much memory requires reserving.
> Another example: let's say you wish to estimate how much
> memory/bandwidth/time is required for the serialization of a compound
> Lisp object between two (LISP) nodes located in remote locations on
> some network, assuming already that the other node is running the
> same version and has the same class definitions on hand. Without
> knowing the RAW number of bytes you will not be able to make an
>> Perhaps your objection is that this thing should not be called sizeof
>> because it's too reminiscent of the C function.
> I would object as well; it is much easier to expect a similarly named
> function to do the same thing across languages than to remember the
OK, so I can see two objections here, I think:
1. You want the *name* "sizeof" to do what they would expect, from C,
it would. This is fine, I have no issues about what the function is
called, and in any case "sizeof" is not a very Lispy name (size-of
would be better).
2, But actually, as far as I can see, you don't want it to do what it
does in C, I think. because what it does in C, of course, is *not*
return the raw number of bytes: it returns the number of bytes it
would take to store an object, which (as in Lisp) is raw number of
bytes + overhead, where C's overhead is typically padding. (This is
why, despite the non-lispy name, I thought "sizeof" was reasonable,
because it does the equivalent thing for Lisp that it does for C).
So, what do you want sizeof to do? In your first example of copying
Lisp data to some foreign language (say C), what you need to know is
what *C's* sizeof returns for the struct you've defined in C to hold
the data. This is not the raw bytes, and I don't think it is easily
derivable from them as it depends on layout (and perhaps compiler
options - doesn't x86 support misaligned access? Do any compilers
generate code which does this (I hope not)).
In the case where you're considering transmitting data over some
network stream then what you want is probably the raw bytes, but this
is not what C's sizeof tells you of course - in other words, if you
were doing this in C, you could not use sizeof for this either, for
So, I definitely don't think a function which returns the raw bytes
used, without overhead, by an object should be called sizeof, because
this might lead you to think that it would tell you, for instance, how
much space it would take in C, which it would not do. As far as I can
see such a function would really only be useful for serializing data:
maybe it should be called "serialized-size" or something.
More information about the Openmcl-devel