Old problem with performance

[Weed]

Don пишет:
> Weed wrote:
>> Don пишет:
>>> Weed wrote:
>>>> Christopher Wright пишет:
>>>>> Weed wrote:
>>>>>> Kagamin пишет:
>>>>>>> Weed Wrote:
>>>>>>>
>>>>>>>> Will the language change?
>>>>>>> Hmm... You already has Walter's answer. He's the boss.
>>>>>> I want a more specific answer (yes or no) if possible...
>>>>> It will not. If you come up with some really awesome use case, then it
>>>>> could, but nobody has yet, and the issue comes up every few months.
>>>> Good (I think) use cases have been in this thread
>>> They have not. The examples have been incomplete. You've provided use
>>> cases involving classes, but haven't given _any_ details about the
>>> contents of those classes.
>>>
>>> It's possible that you have indeed found use cases, but you haven't
>>> actually shown them here.
>>
>> I do not understand the claims.
>>
>> For example, any class that implements the mathematical object (matrix,
>> vector, number, etc.) is suitable for example. I think it is obvious.
> 
> Absolutely not! Those cases involve no polymorphism! No virtual function
> calls.

I do not understand why.

They are not principally to demonstrate the problem, but certainly
should be able to use them.

It is possible that in the real code these opportunities are not used,
but tomorrow they may need it, and a day after we again decide to remove
them.

This should not affect the syntax or the choice between the
structures+mixins and classes, and so on!


> 
>> Yes, the discussion in this thread showed that almost always possible
>> for each case to find a different approach, using additives and other
>> scary code. But what if these "perversions" flaw somewhere in the idea
>> of a "reference-only" type?
>>
>> I understand people who are against the changes of language, as they
>> would at least explore these changes. I myself belong to those people, I
>> do not like changes associated with cosmetic amenities, breaking the
>> old-established solution for years.
> 
> I don't think the resistance comes from intertia and committment to the
> "long-established solution". There's plenty of C++ programmers here
> (including myself).

All your opinion. I proceed from the assumption that the programmer
should be lazy. :)  This positively affects the quality of the code and
its reuse

> 
>> I also understand the people who came from the languages Java and C#,
>> which is not familiar with the semantics of the class value.
>>
>> But just such a case, when the inertia hinders the development of
>> language and prevents them winning at least a substantial number of
>> positions. (Namely: the replacement of old C++. Yes, I believe, without
>> C++ replacement functionality D will not be needed.)
> 
>> I think the problem is real and requires action. Not sure it will be a
>> value semantic. Maybe we come up with something entirely new? I do not
>> know.
>>
>> But the problem is that one must at least acknowledge it and not come
>> off the common phrases that "your use cases are not serious" etc.
> 
> You really MUST start from a solid use case. I'm genuinely surprised
> that you've had so much trouble coming up with one; it suggests to me
> that you're not looking at the right problem.
> 

I design a future project. I can not spend time on his coding in advance
knowing that the problem about which we speak will not allow me to
achieve the desired properties of the finished product.

Thus, one can expect from me detailed use cases from real life.

Yes, probably each issue I will be able to circumvent by using tricks,
repeatedly described here. But at what cost? There will be an
unjustified waste of time, the developer and a serious increase of
complexity of the program (compared to C++)