Old problem with performance

[Weed]

Don пишет:

>>>>> That must mean that you inherit that class only to avoid duplicating
>>>>> code. And that is easily done with template mixins.
>>>> It is possible that this polymorphism is not needed and should be
>>>> prohibited for operations by value. The class is ready, why it should
>>>> not be used and have to redo it?
>>>>
>>>> Can not think about changing when the class is ready - he could have
>>>> enormous complexity and hierarchy.
>>> This is the fundamental tradeoff at the heart of the matter.
>>> In D, the choice of whether an object will use polymorphism or not is
>>> considered a fundamental design decision.
>>
>> This is awful! Much easier to give to the application programmer to
>> decide how it will use the derived class somewhere. Such a division
>> should be a basic principle of designing a complex program.
> 
> Even in C++, all of your base classes should be abstract.

Why?

> If you want to move between polymorphism and non-polymorphism in C++,
> it's a non-trivial refactoring.
> 
> 
>>> D gets significant benefits
>>> from this.
>>
>> Benefits:
>>
>> 1. Disappeared slicing
>> 2. ?
> 
> That's not what I had in mind at all. I don't think slicing is such a
> big deal in itself; it's just a symptom.
> 

What do you mean?

>>> C++ allows you to defer the decision, but it doesn't come for
>>> free.
>>
>> Clarify what you mean?
>>
>>> (Generally speaking, statically typed languages do force you to make
>>> more decisions at design time). Notice that you have little gotchas in
>>> C++, such as the need to declare a virtual destructor on every struct
>>> you think you might "someday" use polymorphically. It sticks around,
>>> even if it never gets used.
>>> One of the nice things about a D struct, compared to a C++ struct, is
>>> that you *know* it's simple, it never has that kind of baggage.
>>>
>>> D does choose different trade-offs from C++. If it was always the same,
>>> it'd be the same language!
>>
>> There is no need to compare the structs from C++ and D. In fact, in C++
>> classes and structures are the same.
> 
> Well, although the keywords are identical, there are two different
> varieties of C++ objects muddied together: PODs, and polymorphic types.
> You declare a type to be polymorphic by declaring a virtual function
> inside it. In D, you do it with the 'class' keyword.
> 
> 
>> I like D's idea of POD structs + without them you can not ensure
>> compatibility with C, but it is very important.
>>
>> Now we are talking about classes.
>>
>> In C++ classes with the same problems, such as what they do not have a
>> common base class (Object in D). Passing classes by value is not a
>> problem - is an advantage.
> 
> Passing a polymorphic class by value rarely makes sense.
> You can't get (runtime) polymorphism unless you go through a pointer.

Or reference (&). Thus, even polymorphic class on stack can be used
safely in C++.

> 
>> As I said earlier, the presence of pointers is also an advantage,
>> although they are dangerous and can lead to complex bugs.
> 
> I don't think that is analagous. The issue is not primarily about with
> the 'danger' of passing classes by value. It's about clear separation of
> concepts.
> 
>>> BTW, if you're concerned about performance, you'd do well to use
>>> compile-time polymorphism rather than run-time, when possible. D's
>>> metaprogramming support leaves C++ for dead.
>>>
>>
>> I think if there was a language with all the features as in D but with
>> the model objects from C++, he would have won great popularity. Mainly
>> it would have moved C++ developers who are satisfied with the model
>> classes of C++ but not satisfied with the absence of other modern
>> features: metaprogramming, contracts, delegates, closures etc.
> 
> I think D will get adequate popularity once it has a good library
> situation. It only needs language changes inasfaras they are necessary
> for library design.

What D better than Java or C#?