Old problem with performance

[Don]

Weed wrote:
> 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?

See, for example,

http://www.artima.com/intv/modern.html

> 
>> 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?

Language complexity.

> 
>>>> 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++.

Same thing. You're either not using value semantics, or not using 
polymorphism. Not both at once.

> 
>>> 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#?

I'm wasting my time here. I'll not make any further comments on this 
subject.