On 07/11/2012 04:16 PM, deadalnix wrote:
On 11/07/2012 16:16, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
And sometimes it is not known in advance if it will be accessed at all.
And this is somewhere in a class that seems unrelated to the object
that wants to compute a string representation/hash value/comparison.
It is not the simple cases that are an issue.
Arguably, this is a software design problem. I never encountered a case
where I need to do such thing and never encountered something similar in
code except code that demonstrate trick or subverting language
features/librairies in unexpected ways (which is always fun to do, but
should never ends up in production or be promoted by a language/a lib).
By the way, I'd be happy to be proven false, but I think the issue is
overstated here.
Frankly, there is no real issue. It is always possible to sidestep the
built-in syntax-sugared library-supported functionality. The
inefficiencies caused by the unused vtable slots are likely neglegible.
It's just not something one wants to do nor encourage to do.
