division of objects into classes and structures is bad
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Dec 30 08:36:35 PST 2008
Weed wrote:
> 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++).
There is a niche of cases where using the C++-style duality of classes
and structs is useful. I think those cases are marginal, and that the
conceptual division fostered by D is the better way to go because it's
clean and avoids a lot of the inherent problems of duality.
Andrei
More information about the Digitalmars-d
mailing list