Georg Wrede wrote:
Andrei Alexandrescu wrote:
* "Resources come and go; memory is forever" is the likely default in D resource management. This means that destroying e.g. an array of File objects will close the underlying files, but will not deallocate the memory allocated for them. In essence, destroying values means calling the destructor but not delete-ing them (unless of course they're on the stack). This approach has a number of disadvantages, but plenty of advantages that compensate them in most applications.

I admit I'm tired right now... You mention disadvantages, the one I can't avoid thinking of is memory leak! Which means you can't write e.g. a simple web server that opens and closes files, instead of creating and managing a file object pool? Eventually it'll run out of memory, unless I'm way too tired now...

Better said, I was too tired when I posted that. I gave too little detail. Files are resources, so they will "come and go", i.e. will be under deterministic control; there's no need to worry. Only memory will have a "lives forever" regime for safety reasons. It's not really forever as the GC collects it. In short, my proposed system is to admit that GC is good _only_ for memory, and that deterministic management must prevail for other resources. I'll get back later on this.

* std.matrix will define memory layouts for a variety of popular libraries and also the common means to iterate said layouts.

I assume this is for handy and practical rectangular (and cubic, etc.) "arrays". Which would be most welcome.


This "memory is forever" philosophy, is this discussed in depth somewhere? (With the current amount of traffic here, I simply can't follow every thread anymore. :-( )

I decided to curb my posting as well. Beyond a point even passable content becomes just white noise. Also since we don't have an off-topic group, off-topic discussions tend to carry on here as well and are not trivial to ignore. I'm happy they are civilized (congrats to all involved).


Andrei

Reply via email to