"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.242.1328986002.20196.digitalmar...@puremagic.com... > On Saturday, February 11, 2012 19:00:51 q66 wrote: >> What's so difficult on that? Slices do not require the GC, you >> allocate once, slice many times, deallocate once. > > With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are > slices.
But not all slices are slices of dynamic arrays. > _None_ of them own their own memory. The GC keeps track of whether you > have any slices for a particular memory block and deals with freeing up > wth > the block if you don't. However, if you allocate a dynamic array without > the > GC, then all of a sudden, it effectively owns its own memory, so the > semantics > of dealing with arrays and memories changes drastically. What happens when > you > slice it? Which one owns the memory? What happens when you try and do > stuff > like popFront on an array? All of a sudden, you have memory which is no > longer > referenced. It's been leaked. > > If you have a very careful scheme for handling memory, you _can_ slice > arrays > without a GC, but you have to worry about all the bookkeeping of keeping > track > of the originally allocated memory and how many slices reference it so > that > you can free it when appropriate. > Yea, manual memory management is hard and you have to be careful. That's true slices or not. > Also, you can't concatenate to arrays at all, because that requires the > GC. > That's true (at least without providing some way to provide an alternate concatenation allocator). But nobody said that all D features would be usable. > So, you're dealing with a mine field if you try and use D's array > capabilities > without a GC. Yes, you _can_ use some of them if you're _very_ careful, > but > I'd seriously advise just sticking to using arrays like you would in C > except > for the fact that arrays know their length. > Arrays knowing their own length *is* a notable improvement over C.