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