division of objects into classes and structures is bad

[Weed]

Don пишет:
> Weed wrote:
>> Denis Koroskin пишет:
>>
>>>>  80490eb:       8d 85 6c fe ff ff       lea    -0x194(%ebp),%eax
>>>>  80490f1:       50                      push   %eax
>>>>  80490f2:       8d 85 2c fb ff ff       lea    -0x4d4(%ebp),%eax
>>>>  80490f8:       e8 67 ff ff ff          *call   8049064*
>>>>  80490fd:       e8 62 ff ff ff          *call   8049064*
>>>>     return c2.i;
>>>>  8049102:       8b 85 cc fc ff ff       mov    -0x334(%ebp),%eax
>>>> ...
>>>>
>>>>
>>>> (in 80490f8 and 80490fd simply two calls successively)
>>>>
>>>> If structures and classes were same that excellent optimization in any
>>>> case would turn out
>>> If that's your use case, then your should seriosly reconsider using
>>> struct instead of class for your objects.
>>
>> Classes always give such overhead if them to use in such quality. For
>> example, classes basically cannot be used as any mathematical objects
>> using overload of arithmetics. But also not only arithmetics, it it is
>> simple as a good example.
>>
>>> Alternatively, you can use +=
>>> instead.
>>
>> Here yes, but if I add classes of different types? Then not to escape
>> any more from creation of the temporary object in the heap.
>>
>>> Other than that, this is not a convincing argument.
>>>
>>> Reading many of your posts I came to a conclusion that you are
>>> shortsighted and too crazy about performance. What you care about is a
>>> premature optimization, which is a root of all the evil. You should
>>> ensure that your programm is complete and correct, first and *then*
>>> start doing profiling and optimizations.
>>
>> The program is already ready. It entirely consists of the various
>> mathematics. Approximately %30 times of performance are spent for
>> similar superfluous work. On C++ the program will work on %30 faster (I
>> hope :)) and on D I am will turn out to do nothing with it.
>>
>>
>>> Going back to the topic, dividing user types into two cathegories
>>> (structs and classes) is considered modern and right.
>>
>> I do not accept such argument:)
>>
>>> Some languages
>>> lack structs support at all (e.g. Java), but structs are too useful for
>>> optimization and language interoperation to drop them in a systems
>>> programming language. Some lack classes and try doing everything with
>>> structs (C). D takes the best of both worlds.
>>
>> Probably I have not understood something, but I do not suggest to refuse
>> structures in general. I suggest to allow to create classes on a stack
>> as it is made in C++. That is actually to make structures and classes
>> same, than they and are, for example, in C++.
>>
>> In the initial message I have shown that for perfomance important that
>> the class could be transferred and on value. And it not artful premature
>> optimisation - objects on value always so are transferred, all
>> programmers know it and use when do not wish to allocate a place in a
>> heap, that is usually always when the object will live in {}.
>>
>> Besides, a class in a stack it is normal - keyword addition "scope" for
>> classes too speaks about it.
>>
>> Rigidly having divided classes and structures D deprives of the
>> programmer of some possibilities which give it C++-like languages. I
>> consider that such languages should give all possibilities which allows
>> CPU but hiding concrete architecture, otherwise I would choose less
>> difficult in use language.
> 
> Use classes if you want polymorphism. Otherwise, use structs. It's a
> clear distinction, which is not at all arbitrary -- there are
> significant implications for the generated code.

And if polymorphism is necessary and such calculations are necessary as
I have above described? To emulate polymorphism with the mixins? Or
simply to reconcile to such obvious losses?

I about that that division into classes and structures in language D
automatically reduce perfomance of programs. Unlike languages where this
division is not present (C++).