Re: C structs library

[Ben Kelly <ranavin@...>]

Sam Roberts wrote:
> 
> Maybe this is useful to someone. Unable to find a succinct summary of
> the differences between struct and pack, and frustrated by the
> mostly-but-not-quite overlapping feature sets, I wrote up this
> description of the choices.
> 
> YMMV, but for background, we currently are using pack, chosen at
> random a few years ago, and I am absolutely not looking for some
> heavyweight object-to-binary mapping library.
> 
> ## vstruct:
> 
> Lots of code, include a lexer/parser, compiled patterns, etc. Definitely not
> trivial to read.
> 
I've tried to keep things fairly organized, and 1.1 is in general more
readable than 1.0 - but it could definitely use more commenting, and
probably a bit of a refactor.

> However, looked like it had good support for complex structures, and I
> particularly liked its syntax for packing/unpacking directly into tables,
> including tables with named fields. Also supports bit fields, including named
> bitfields.
> 
I'm working on 1.1 beta 2 which includes bit streams, too (which are
really just a more general form of bit fields). Not sure if this is
useful to you.

> Its almost completely native lua, though whether that makes a difference to us
> is not clear, we usually run too fast, not too slow.
> 
It's actually written entirely in Lua; this simplifies distribution but
has performance implications. If desired, it is possible to rewrite
individual parts of it in C - in particular, any of the format
handler modules in io/ can be replaced with C modules and it won't
notice (assuming your package.cpath is set up right).

Not much has been done in the way of performance analysis for this
library, since it's targeted at non-performance-critical applications;
as a general rule, if you just need it to be "fast enough for end
users", it probably is, whereas if you need realtime responsiveness,
network traffic decoding, or the like, it probably isn't.

> Patch vstruct with the changes from the mailing list.
> 
What changes? Please point me at the right thread - if someone's posted
a patch, I'd like to incorporate it into master.

> Add _ to vstruct to mean "underlying endianness"
> 
vstruct already has = for "native endianness", as well as < and >. Or am
I misunderstanding what you mean by "underlying endianness"?


	Ben