[saga-rg] Task model...

[Hartmut Kaiser]

Tom Goodale wrote:

> >>>>> It is not really much more readable than 4a1.
> >>>>> Therefore, I'm uncertain if it is worth fragmenting our
> approach
> >>>>> to bindings in different languages when there is not a clear
> >>>>> benefit in terms of readability or implementation complexity.
> >>>>
> >>>> I think that 4a2/4a3 actually allow nicer implementations, as it
> >>>> allows to have the different async parts somewhat
> separate from the
> >>>> sync parts.  We think its nicer :-)
> >>>
> >>> 4a3 the only implementation in a C++ like manner I can think of,
> >>> which provides:
> >>> - an interface which conforms to modern C++ concepts
> >>>   pushed by Boost et.al.
> >>> - it avoids not needed overhead if some of the features
> >>>   are not needed/used (this gets optimised away by any
> >>>   decent C++ compiler)
> >>
> >> Well, if the compiler can actually take advantage of that
> syntactical
> >> convention to apply more efficient optimizations, then that is a
> >> clear advantage to that approach (whether or not I find the syntax
> >> obscure).
> >
> > _S_AGA.  If it is obscure to you or others, its not a good choice.
> > Performance is a second order issue.  However, as I
>
> Also, we have not used templates anywhere else in the
> abstract API, so I think it would be a bad idea to move that
> way now.  This does not preclude the C++ language binding
> using such if there is a clear benefit.

I agree here. There was a bit of misunderstanding from my side. You were
talking about the the SAGA spec but I was talking about the C++ language
binding. Could we find a way of doing both, describing a more or less
general interface in the spec and giving some freedom of implementation to
the language bindings?

> On a practical note, templates are one of the least portable
> features of
> C++, especially in libraries (except template libraries), and I would
> strongly urge that we do not use them for SAGA.

We will probably end up writing a C language binding for the affected
architectures in the end anyway... But let's first solve the problem for the
99% of the architectures where your concern is a no-issue. It's a matter of
how much time is required to do the C++ implementation in the end. And using
templates will give a speedup to this for sure.

Regards Hartmut