Old problem with performance

[Weed]

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.

> D gets significant benefits
> from this.

Benefits:

1. Disappeared slicing
2. ?

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

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.

As I said earlier, the presence of pointers is also an advantage,
although they are dangerous and can lead to complex bugs.

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