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++).
To solve a problem it is possible having allowed to transfer classes on value (checking during compilation that has not occurred slicing)