So I now have a working encode function for strings.
The current interface is
type string = "string" requires encoder "string_encoder";
where string_encoder must be a C function
string string_encoder (void *data);
where data points at a string object. Same for other types with
name changes.
This particular case is tested and works: well, it is just
string string_encoder (void *data) {
return *(string*)data;
}
So now the issue is this. For say an int, the encoder ls
string int_encoder (void *data) {
return string ((char*)data, sizeof(int));
}
i.e. just return the int binary. The question is: how to specify
that?
There's no reason for the user to have to write such a function
out: its the same for all types which can be represented by
a sequence of bytes: "string" is an example which cannot be.
However simply leaving out a specification is dangerous!
I am thinking:
If a type is specified as a "pod", then use the binary
image. A "pod" or plain old data type means that the
type has a trivial destructor. This means, in turn,
not to generate a finaliser, because calling it would
do nothing.
This means that the type cannot have controlled
memory or other resource associated with it.
So it should be safe to encode a pod with the
"bitblit" encoder.
For structures and tuples, we can just encode each
component in sequence so the compiler can generate
the encoder. As a special optimisation, if all the components
have trivial encoders, i.e. they're pod's or made out of pods,
then the encoded can be a single bitblit of everything.
With my current design this *includes* pointers because the
pointer handling is external to the detail encoder.
[I have no idea what to do with variants/sums/unions yet :]
The effect is that even functions/procedures can have
compiler generated encoders. We really only need an
encoder for a primitive which "hides" a resource such
as a file handle or memory.
The "default" encoder should then be "abort program",
except for pods.
That's my thought. Any comments?
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
