Re: C++ wrapping

[Gerard Jungman <jungman at lanl dot gov>]

Sorry to bore people with this continuing subject.
But I wanted to say a few more things.

Executive Summary:
   - casting pointers to members is a nice parlor trick
   - maybe std::bind1st and friends are useful
   - has anybody thought about libsigc++ in this context? 
   - templates are not a hack
   - code generation is good for certain well-defined specializations


On Tue, 2004-04-13 at 18:22, linas@austin.ibm.com wrote:
> 
> Well, you must have done this late at night, you forgot about 
> the 'this' pointer. Dohh.  Below follows a non-segfaulting version.

Ah, very good. Victory for the humans.

> Note, however, the non-segfaulting version is still a bit 
> leading, since if 'thing' was a virtual base class,
> and it was used in a multiple-inheritance scenario with other
> virtual bases classes, then the code below would segfault.

Yup. Doom is inevitable.


As an aside to the discussion about lambda, there may be some
partial solutions in the STL binder/adapter stuff, i.e.
std::bind1st, std::bind2nd, std::mem_fun, etc. See Stroustrup
3rd ed, section 18.4.4. I have never used these, but that
just means I am an old dog. If somebody made it clear
that the answer was in there, then I would figure out how
to use them.


On Thu, 2004-04-15 at 13:36, Brian Gough wrote: 
> I wouldn't really advocate using the C-style function-based or
> iterative GSL routines with functions defined by classes in C++.  It
> is too horrible, as demonstrated by the code flying past.

We're all adults here. Anyway, there is an underlying question,
which is about the "right" way for the library to talk to
the client about client-supplied functions.

Brian's basic point, that the methodology in the GUI libraries is
not useful, is probably right. I did a little Qt myself some time
ago and never felt comfortable with it; the metacompiler is an
unacceptable solution. And gnome signals make me queasy (I only use
gnome from python; if I had to use the C interface, I wouldn't use it
at all). Also, the GUI libraries can afford to be wasteful of cycles
in return for a more dynamic model. I would want something that costs
precisely no more than a vtable indirection would cost. Anything based
on strings is not acceptable. Even better (and probably necessary
in the long run) is for most of the cost to disappear at compile
time.

libsigc++ makes some sense. I don't know what the implicit
costs are, but it is certainly more efficient than the Qt
mechanism, and it does seem to eliminate some costs
at compile time. Maybe it is still too confusing for the
average user of numerics. But maybe we could hide some of the
complexity by some wrapping/remapping/renaming hooha.
I don't think an average user should even have to know
what a signal or slot is.

http://libsigc.sourceforge.net/


The idea that code generation is the answer... well, I don't know.
It makes sense for a limited problem, like generating a BLAS, or
even a LAPACK. ATLAS is clearly a good thing. But this is really an
implementation issue. In the end, I don't care how you created an
underlying linear algebra implementation. I just want it to work.

Finally, about Brian's comment that C++ templates are hack: Qt MOC
is a hack. Any strategy based on an external parser is a hack.
An example that comes to mind is SWIG. Well-meaning and useful,
but basically a hack. The reason that these are hacks is that
they are essentially a big switch statement (or worse, a big
perl script); the philosophy is, get something that works on
most cases and punt on the rest.

But any tool which is complete in its domain is not a hack; with
such a tool you can do things that the designer never thought of
and didn't have to special case for. You may not like templates,
but they are clearly complete, in several senses of the word.

Templates may not solve the problem of generating a special-cased
LAPACK in the most appealing way (in fact, I think code generation
makes more sense in this case), but that is not really the question
at hand, which is how to provide a clean interface to parametrized
algorithms, including the case when one or more parameters is
a function object.


On Fri, 2004-04-16 at 18:45, linas@austin.ibm.com wrote: 
> 
> Since GSL 'already works' in C, it doesn't have to be driven in this way.
> So I guess the whole point of having a GSL C++ is to have an *elegant*
> GSL C++, since one has the luxury of putting off the solution until
> one can do it really really well...

Exactly. We can at least dream about doing it The Right Way.
"Choose the form of the destructor..."


-- 
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory