Possible way to achieve lazy loading with const objects

Jonathan M Davis jmdavisProg at gmx.com
Wed Sep 28 14:09:59 PDT 2011


On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
> On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
> >> "Jonathan M Davis" , dans le message (digitalmars.D:145479), a écrit :
> >> > But since lazy initializion will _never_ work with immutable
> >> 
> >> Never say never. One could build a clean and thread-safe way to lazily
> >> initialize fields. Like someone said, even without mutex, if the
> >> function to compute the variable is pure and based on immutable data,
> >> the worst case would be to run the intializing function twice. And the
> >> langage could include mutexes to do prevent that to happen. The fact
> >> that immutable data could, one day, be put in ROM doesn't mean that it
> >> has to. The close issue is like another-one said the issue of
> >> memoization of pure methods.
> > 
> > The very fact that an immutable variable _could_ be put into ROM negates
> > the
> > possibility of the semantics being such that you don't have to fully
> > initialize an immutable variable up front.
> 
> No it doesn't. If it's in ROM, initialize eagerly (which should cost
> nothing, done at compile-time). If it's not, initialize lazily.

That's assuming that objects can only ever be put into ROM at compile time. Is 
such an assumption valid? And not just currently valid, but permanently valid?

Though I suppose that even if that assumption isn't valid, the compiler should 
still know when it's putting something in ROM and force eager loading it that 
case.

However, that does introduce the whole locking issue again, since immutable 
variables are implicitly shared.

- Jonathan M Davis


More information about the Digitalmars-d mailing list