On Fri, 19 Jun 2009, Roy Stogner wrote:
> On Fri, 19 Jun 2009, Tim Kroeger wrote:
>> I tried to do this now, see attached patch.
> At first glance, the core of this patch looks exactly like what I had
> in mind. I'll want to spend some time testing (and ideally get some
> reassurance from Jed) before making such a major change to such a
> critical class, but this looks good.
Okay. In any case, what will happen to the new method
NumericVector::get() that is still in the patch? Will you keep it or
not? I'm asking because I already use it in part of my application.
If you will not include it in the library, I should revert the changes
in my application as soon as possible (since in a couple of weeks I
might have forgotten what I did exactly). On the other hand, if you
keep it, I see no reason for reverting my code since the new method is
in any case faster (although, if you manage to avoid the virtual
function call overhead, the difference will reduce to the check that
_array_is_present is already true, which should really be negligible).
>> However, I currently don't see how you want to get rid of the virtual
>> function call overhead. I kept my new API for the while, as it is
>> still somehow faster (although the differce is less pronounced).
> Just an idea I ran by Ben recently over the phone; I hadn't mentioned
> it on the list yet.
> Although I don't want to get rid of the ability to do (limited) mixing
> and matching of different linear algebra packages in the same code,
> most users want to just pick one package and use it for every relevant
> object. We could move the current base classes to NumericVectorBase
> and SparseMatrixBase, make NumericVector and SparseMatrix into
> compile-time-selected typedefs of e.g. PetscVector and PetscMatrix,
> and then declare all the leaf class functions non-virtual. AFAIK this
> still allows a C++ compiler to call those functions virtually from
> pointers/references to the base class but also allows the compiler to
> inline them when they're called from pointers/references to the leaf
I'm not quite sure about this. In particular, I would think that
inlining is only possible if you're calling from a local instance of
the leaf class, but not from a pointer/reference to such a class.
The reason is that I don't see any possibility for the compiler to see
that your leaf class is really a leaf class, i.e. any user code could
inherit further down and overload virtual functions and pass a
pointer/refernce to such a class to the basic library. C++ is missing
a syntax for explicitly disallowing inheritance from a class, isn't
Even if it works theoretically, I see another problem: Of what type
will, say, LinearImplicitSystem::solution be? Will it be (an AutoPtr
to) NumericVectorBase or NumericVector? In either case, you can't
have both the flexibility to mix solver algebra packaes and the
possibility to inline virtual functions.
Anyway, I'd like to be proven wrong. Also, compile-time selection of
the linear algebra package would be fine for me since I'm only using
Dr. Tim Kroeger
tim.kroeger@... Phone +49-421-218-7710
tim.kroeger@... Fax +49-421-218-4236
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany