Re: Variable Argument Lists, how to handle?

[Christian Borup <borup borup com>]

On man, 2002-10-28 at 15:37, Guillaume Cottenceau wrote:
> "Marin Purgar" <m purgar extracom de> writes:
>
> > What should be the preffered way to handle the methods accepting variable
> > argument lists?
> >
> > For now some of the implemented methods use perl 'proxy' methods which are
> > converting arrays/hashes to references and then passing them to the
> > underlaying inline function/method.
>
> The advantage of that is to move some code out of C and have it
> in Perl in the .pm; my opinion is that the most perl code we
> have, the better.

You argument does make some sense. But the code needed to manipulate the
array/hash references are of equivalent complexity to the stack
manipulation code...

But anyway I have no problem with using perl proxies. If they turn out
to be too inefficient moving them to C should be no problem.

> I'm seriously considering the ability to have something automatic
> (or not) to convert all the Inline .c into one large .xs, at
> compilation time (e.g. not in the CVS) (at the end of the
> development, or at least when we have something usable) so that
> we don't have a large number of .so files, but only one, because
> I suppose/hope this is why gtk2-perl takes more memory than
> gtk-perl, and has a much higher program startup time.
>
> If we begin to use Inline-specific things in the .c, it would
> make this far more difficult.

Isn't it possible to make Inline generate just one .so?

Also folding all the .pm's into just one Gtk2.pm might speed things up a
bit. But really only a benchmark can tell. Also it would rid the
scripter from having to "use" every widget used, not even C programmers
have to endure that. 

The old gtk-perl useses a lot of tricks to stay fast. Maybe you can get
some hints there.

./borup