Possible way to achieve lazy loading with const objects

[Peter Alexander]

On 29/09/11 8:01 PM, Steven Schveighoffer wrote:
> Again, I ask, what is a real-world example of something that needs lazy
> caching (or where lazy caching significantly helps performance) for
> comparison. You have already stated that you appreciate it's not const,
> so you must have *something* that needs it.

1. A renderer lazily caching world transform matrices.

2. Collision detection queries often cache recent intermediate results 
due to spacial coherency between queries.

3. A simple asset loader may lazily load assets on demand (rather than 
having to eagerly load things up front).

4. String hashes are cached all over the place for fast resource look ups.

I'm honestly quite amazed that I have to justify my belief that caching 
is useful, and commonly used. Caches are everywhere: your CPU has 
multiple levels of caches, you hard disk has caches, your browser 
caches, domain lookups are cached; and they're all lazy, too. Lazy 
caching is a cornerstone of optimisation.


> So far, I don't think it's a very common requirement. It certainly
> doesn't seem like it's so important that the entire body of D code in
> existence should have to deal with mutable opEquals. The fact that it's
> mutable now is really a legacy D1 issue.

Inline assembler isn't a common requirement either, but that's no 
argument to ignore it.

I suppose something like __restrict isn't very important to you either. 
It's certainly used a lot less than lazy caching. However, it's worth 
pointing out that __restrict was introduced into compilers through 
popular demand by people that needed it. These things are real and 
should not be ignored.