Andrei Alexandrescu пишет:
> 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.
It is very a pity.
My small opinion: it is impossible to reduce performance for struggle
against potential errors - such languages already are, it more
high-level. It how to refuse pointers because they are dangerous,
difficult for beginners and without them it is possible to make any
algorithm.
What is D?
D is a general purpose systems and applications programming language. It
is a higher level language than C++, but *retains* the ability to write
high performance code and interface directly with the operating system
API's and with hardware.
http://www.digitalmars.com/d/2.0/overview.html
