2009/2/21 Weed <[email protected]>: > 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
