Hi Paul,
> Also, how hard would it be to add methods to the struct? For example,
> after creating an Inline::Struct, creating an Inline::C read() method
> in that package space? Would it be that easy?
It should be pretty easy. For instance, let's modify my previous example:
----8<----
use Inline C;
my $o = new Inline::Struct::Foo;
$o->read;
$o->Print;
package Inline::Struct::Foo;
sub read { ... }
sub Print { ... }
__END__
__C__
struct Foo {
int inum;
double dnum;
char *str;
};
typedef struct Foo Foo;
----8<----
> > FEATURES
> > o Adds two new configuration options to C and C++:
> > STRUCTS:
> > Takes either the name of a struct, or an array ref containing a
> > list of structs to bind.
>
> I assume that if this option is present and a struct is specified which
> is not in the list, that struct is left unbound.
Correct.
> hmm -- sounds good, but you might want to add another level of
> abstraction, such as "if it's an array REF, and the number of elements
> in the referenced array match the number of fields in the struct...."
>
> That limits the flexibility it has now, but would circumvent the
> following problem --
>
> > -- elsif the number of args is divisible by 2, assume it's a
> > "hash" assignment: new Foo(str => 'neil', inum => 10).
> > Any unassigned items remain zero'd.
>
> This is great, but what if there is an even number of elements in the
> array, and you want to assign to exactly half of them? This setup will
> read that the args passed match the number of elements in the struct,
> and the previous step will catch it before it gets here (which may be
> disastrous, depending on how you handled the type conversions...)
>
> If the above requires an aray ref, you can't have that problem. You
> might want to require or allow a hash ref here as well just for
> consistency, or whatever, but watch for this as a possible bug. Yes?
Damn! I hadn't thought of that. You're probably right -- maybe I'll use an
array ref. On the other hand, why not a hash ref? I'll think about it
more.
> > -- else croak.
>
> Croaking is probably best, but you might consider checking to see if
> there's exactly one arg and it is in fact another instance of the same
> struct type, in which case you could clone it. I wouldn't, but I just
> thought I'd toss out the thought in case it sounded good to you
> (lol....)
Well, that might be useful... I'm not sure though. Then I'd have to do a
deep copy, and that's something I don't want to bother with.
> > DESTROY -- frees the C structure, iff it was allocated by Perl.
>
> I presume that "iff" is an "if-and-only-if"?
Yes.
> > _HASH -- returns a hash ref containing the field/value pairs.
> > _ARRAY -- returns an array ref containing the field values.
> > Struct order.
> > _KEYS -- returns an array ref containing the field names.
> > Struct order.
> > In addition, each field generates a method of the same name. If
> > you pass it no arguments, it returns the value of that field.
> > If you pass it an argument, it sets that field and returns the
> > object, so that you can chain such assignments:
> > $o->inum(10)->dnum(3.1415);
>
> That's very cool. Odd (to me at least), but *very* cool.
> Quick question -- what if one element of a struct is a pointer to
> another struct of a bound type? Could you say
>
> $struct1->struct2()->subelement(); # ???
Absolutely! Currently there's a caveat: you can't have a recursive
structure. That is, you can't have a linked-list struct, because I only
bind to things which are in the typemap, and the struct isn't added to the
typemap until after it has been defined. So this:
struct Node {
struct Data *data;
struct Node *next;
};
would not be bound to Perl, because 'struct Node' has not been defined at
the point where 'next' is defined. Changing the grammar should be
possible, but it's low priority IMHO.
> > - typemaps: For each struct, it generates a typemap so that you
> > can pass struct objects back into Perl from C functions, or vice
> > versa.
> > - convenience macros:
> > INLINE_STRUCT_NEW(target, type) -- allocate a new <type>
> > INLINE_STRUCT_FIELDS(type) -- returns number of fields in <type>
> > INLINE_STRUCT_INIT_LIST(target, type) -- inits target from ST()
>
> ST()?
The Stack. Sorry.
Thanks for your suggestions,
Neil
