Old problem with performance

Bill Baxter wbaxter at gmail.com
Fri Feb 20 12:31:02 PST 2009


2009/2/21 Weed <resume755 at mail.ru>:
> Kagamin пишет:
>> Weed Wrote:
>>
>>> Good (I think) use cases have been in this thread
>>
>> They may be good, but they don't show what can be done in C++ and can't be done in D. You were advised to use structs for value semantic.
>
> We are beginning to repeat itself. Okay. :)
>
> On D you may write anything. Even without cycles! With only "if" and
> "goto" keywords. The question of the costs of such a code.  :)
>
> An example is unnecessarily complex code here:
> http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d
>
> See line 227, template MultReturnType(ArgT) {
>
> This template is necessary to receive by value a structures containing
> the vectors and matrices as mathematical operations results. Receiving
> the vectors and matrices by value in structures needed to increase
> performance.
> Try to add here another 3 or 4 types of the returned object to this
> template?

I think I answered this already, but here goes again:

1) D2 has auto return type deduction, so this whole template probably
isn't necessary in D2, you just use typeof(return) instead, IIRC.

2) A better way to manage the case where you are concerned about
supporting any kind of user type is to have the caller supply a
"traits" template that describes how the type implements the
underlying concept, how to access an element in a generic way, etc.  I
didn't do that in the above code because A) I hadn't figured that out
yet, and B) I moved on to the next thing once I had something working,
and the above was doing what I needed it to do.

> In C++ vector, matrix, and all other possible objects would have been
> the class derived from common base class and this problem does not occur.

I'm sure if you look you can also find many C++ matrix classes that
are not written that way.  Probably fewer are written the way you
suggest, actually.  But as always you're plenty vague about what you
mean here.   Do you mean the mult function would return a generic
Matrix type?  That function does a by-value return.  You'd have
slicing if you did that with polymorphic classes.

Actually from what I've seen, most C++ matrix libraries that support
generic types do so by heavy use of argument-dependent lookup (ADL)
aka Koenig lookup.   Basically you just define your own mult<MyType>
specialization in your own header (or maybe you use the generic mult
template, but have a specialization GetElement<MyType> in your own
header.  There are various ways to do it).   The way C++ works, these
will get used by the generic template if they are the best match.

D doesn't have ADL, and I griped about it for a while because it makes
porting those kinds of C++ code difficult.  But in the end I think
that style of programming leads to maintenance headaches.   You see
GetElement being called in some module you're reading and you want to
see its definition -- it could be anywhere!   With the D/traits
approach I mentioned above such code must be injected explicitly into
the template via a parameter of some kind, which gives the maintenance
programmer a little bit better chance of finding where it comes from.
It may not be so much better, but anyway it seems to allow you to do
the same kinds of things you could do with ADL.

If you want to go the polymorphic route with D you can.  As I think
has been pointed out plenty.

Why don't you just show us the class in the way you would like to
write it in C++, and we'll show you how to write it in D, or finally
agree with you that it's not possible.   But as long as you continue
to be hand-wavy about "common base classes" we're at a bit of an
impasse.  So far everyone thinks D can do what you want it to do based
on your vague descriptions.

--bb



More information about the Digitalmars-d mailing list