octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lvalue list optimizations


From: Jaroslav Hajek
Subject: Re: lvalue list optimizations
Date: Thu, 5 Aug 2010 19:23:16 +0200

On Thu, Aug 5, 2010 at 6:28 PM, John W. Eaton <address@hidden> wrote:
> On  5-Aug-2010, Jaroslav Hajek wrote:
>
> | as some of you may noticed, I recently implemented a simple method of
> | propagating lvalue list information into functions. Within m
> | functions, the isargout function can detect which outputs are being
> | ignored using ~ and possibly skip certain computations. This is a
> | generalization of the usual conditional output evaluation using
> | nargout. The latter is usually sufficient, but there are some
> | functions where output argument order is dictated by consistency and
> | omitting a leading output simplifies the operation. In Octave's
> | library, sortrows and histc are an instance.
> |
> | Now I would like to make this information available to the DEFUNs. The
> | cleanest way is to simply pass an additional argument. Is it OK to
> | change the signature of a DEFUN? The macros DEFUN and DEFUN_DLD would
> | be preserved (and declare the extra argument as ignored).
>
> I don't object to an additional macro that accepts the new parameter
> as long as the old ones continue to work as they do now.  I assume you
> would only use the new macro(s) in cases where the extra parameter is
> actually needed, correct?
>
> jwe
>

Yes, definitely. I'd define DEFUNL(name, args, nargout, lvalue_list,
docstr) and have DEFUN call DEFUNL with empty lvalue_list name, so
that the corresponding parameter would end up unnamed. However, the
actual signature of all DEFUNs would change from
octave_value_list (*) (const octave_value_list&, int)
to
octave_value_list (*) (const octave_value_list&, int, const
std::list<octave_lvalue> *)

i.e. code that relies on the former signature will no longer work
(code using the octave_builtin::fcn typedef will work). Additionally,
this will mean that there will be zero binary compatibility between
3.2.x and 3.4.x. I don't think that matters, however.

what do you think?

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]