Re: value extractors for octave_value class

[Jordi Gutiérrez Hermoso]

On Thu, 2015-11-12 at 11:46 -0500, John W. Eaton wrote:
> On 11/11/2015 11:21 PM, Jordi Gutiérrez Hermoso wrote:
> > On Wed, 2015-11-11 at 11:59 -0500, John W. Eaton wrote:
> >
> >> When overloading these functions with (for example)
> >>
> >>     Array<double> vector_value (const char *fmt, ...) const;
> >>
> >> some compilers complained that the overloaded function was ambiguous.
> >> I'm not sure what is best here.
> >
> > How about just overloading with std::string arguments and requiring
> > the function caller to use sprintf in case they need formatting?
> >
> > So, for example,
> >
> >     auto x = foo.int_value(sprintf("error: want %s but got %s", bar, baz))
> 
> I don't think we should be using "auto" in Octave code just yet.

Yeah, I didn't really expect C++11 in Octave yet. It was just force of
habit.

> Some reasons to not do this are that sprintf requires a buffer to be 
> allocated, so that would complicate things and the sprintf operation and 
> the std::string object creation would happen on each call even if they 
> are never needed.  With the fmt+varargs approach, the arguments just 
> need to be passed (as pointers) and if the error doesn't happen, then 
> the formatting doesn't have to be done.

Okay, it might not be the speediest thing to do, but I'm also not sure
it would make the interpreter that much slower. It's not like the
value extractors are typically in deeply nested loops. They're usually
near the top of function calls just to get the data before doing
something with it.

Barring that, I don't think there's much of a better solution within
C++03 than the ones you already proposed. There are things that could
be done with C++11 variadic templates or even with simpler things such
as C++11's std::tuple (actually, not much different than a variadic
template).

And if you're replacing error_state checks, it seems about the same
amount of lines of code to replace them try-catch blocks, so I don't
see why try-catches seem so onerous. You can still have a try-catch at
the top-level of the interpreter for all conversion errors.

- Jordi G. H.