Old problem with performance

[Don]

Weed wrote:
> Don пишет:
>> Weed wrote:
>>> naryl пишет:
>>>
>>>>>>>>> --bb
>>>>>>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=83506
>>>>>>>>
>>>>>>> You should use a struct there!   Your code does not show you doing
>>>>>>> anything that would even remotely suggest using a class is
>>>>>>> worthwhile.
>>>>>>>  You're doing value operations on value types.  That's what structs
>>>>>>> are for.
>>>>>>     
>>>>>> Why?
>>>>>>
>>>>>> What if I have not substantiated the fact that c1 is a class I should
>>>>>> use there a structure?
>>>>>>
>>>>>> Used in D a model of placement classes only in heap have a rule "if
>>>>>> you
>>>>>> made the class and trying to pass it by value is somewhere in your
>>>>>> code,
>>>>>> there is a design error?
>>>>> Explains why the question is given in this form:
>>>>>
>>>>> I am received or wrote a classes. Is it right to overload the operator
>>>>> opAdd and use them? I think yes.
>>>>>
>>>>> But why not allow this operation at the same speed that allows C++?
>>>> If you pass it by value you'll lose polymorphism.
>>> Debatable
>>>
>>> By the way, in my example the transfer class by value is not
>>> important(!), it is important to create a temporary class on the stack.
>>> Then we can pass a reference without problem (C++ allows this through
>>> the "&")
>> Sure, but you're not using polymorphism.
>>
> 	
> There is no, but the same object can be used in other places, including
> the polymorphism
> 
>>>> 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.
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.

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

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