Great. Let's see if/how this list works.
Edwin Wiles wrote:
> I've already thrown a few notes together for a perl5 module, but nothing
> I'm ready to share just yet. I need to dig through CPAN to make sure
> I'm not reinventing something.
When you are ready to share, I'll be glad to peruse.
> I hadn't even considered doing a 'partial' unpack. It would seem to be
> quite inefficent to me. Just go ahead and unpack it right up front, and
> then repack it when the user asks for a packed version of the data.
As a module, it probably would be inefficient to do a partial unpack. As a
built-in, it might be practical, especially to look at a few values in a large
structure.
> I like the idea of having non-rigid data elements, but I'm doubtful
> about a generic enough method to support the various possible formats.
> (Of course, I'm already considering methods to handle the more complex
> entities, such as nested descriptions.)
The most important stuff is the fixed size structures of fixed size types. But if
there's room, or if it isn't too hard...
If the method allows typed data elements of variable length, then if the
variability of one element is allowed to be defined in terms of another, great
flexibility can be achieved... i.e. (borrowing liberally from C syntax to avoid
suggesting one for Perl):
struct foo {
char count;
char string [ count ];
}
struct foo2 {
asciiz string;
}
struct foo3 {
short count;
char string [ count ];
}
Clearly foo3's counted string has a bigger count field than foo's. And foo2 uses
a null terminated string. Modifying count would change the space available for
string. For the asciiz string, modifying the string would reallocate sufficient
space in the packed version.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
