November 20, 2006
My mistake, this will only work if each is addRange()'d instead of searched by pool.

-[Unknown]


> Yes.
> 
> std.gc.removeRange(myArray);
> 
> As far as I recall.
> 
> But, iirc you do have to do this on a full range (e.g., not a sliced array but the whole allocated array.)
> 
> -[Unknown]
> 
> 
>> Mars wrote:
>>> http://www.osnews.com/comment.php?news_id=16526
>>
>> RE[2]: Not much of an update
>>  > By luzr (2.10) on 2006-11-19 19:44:17 UTC in reply to "RE: Not much of
>>  > an update"
>>  >>I second that. D is a very nice language with a clear focus. My first  >>impression was that it has the best of Java, the best of C++ and none  >>of they're major weaknesses.
>>  >
>>  >Adds one major weekness - its memory model is based on conservative GC, >which makes it unpredictable and in reality unusable for some important >applications (like cryptography or any other software that deals with >noise-like data).
>>
>> This is one thing that bothers me with the current GC. If you store data with a lot of entropy in an array (Sound, encrypted data, sensor data, etc...) you start to experience memory leaks because the GC starts to see the data as references to other objects.
>>
>> Is there a way to tell the garbage collector "don't look for references here" without using malloc and friends?
>>
>> This would be for a standard sliceable garbage collected array with any kind of data except references. Something like gc.doNotLookForReferences(myArray) would be nice.
November 20, 2006
Georg Wrede wrote:
> BCS wrote:
>> One issue brought up is that of D "requiring" the use of a GC.
>> What would it take to prove that wrong by making a full blown standard lib that doesn't use a GC, and in fact doesn't have a GC?
>>
>> It would be painful to work with but no more so than in C++. OTOH with scope() and such, it might be easy.
>>
>> Anyway, just a thought.
> 
> Having such a library would make a huge difference in every C++ vs D discussion! The opposition would have a lot less ammunition against us.

The ones who don't want to use D will find the first excuse, valid or not. Fix the excuse, and they'll just move on to the next excuse, valid or not. It's a fool's game. I've been around that circle before. The people we should listen to are the people who actually *use* D, not the ones who just glanced at a chart looking for fault.

The poster who claimed that conservative gc is somehow incompatible with cryptographic software is misinformed. Even if he were correct, the cryptographic buffers could be allocated with malloc() and would then have no effect whatsoever on the gc.
November 20, 2006
Bill Baxter wrote:
> Indeed.  The people who really need to be GC-free are a tiny minority. Wasting a lot of manpower creating a non-GC library just people who don't want to convert from C++ will have one less justification for not using D sees like a huge waste of effort to me.

I translated Empire from C to D. It worked fine, and did not use the gc at all. It didn't require a new runtime library.
November 20, 2006
Dave wrote:
> But the whole concern centers around two canards: a) GC is really slow and b) malloc/free offer deterministic performance for real-time appplications.
> 
> I actually think that the best defense is dispelling those two myths. a) for D will come in time and b) is just plain not true for general purpose malloc/free implementations on modern operating systems.

If you talk to the people who actually do real time software, they don't use malloc/free precisely because they are not deterministic. They preallocate all data.
November 20, 2006
Walter Bright wrote:
> Dave wrote:
>> But the whole concern centers around two canards: a) GC is really slow and b) malloc/free offer deterministic performance for real-time appplications.
>>
>> I actually think that the best defense is dispelling those two myths. a) for D will come in time and b) is just plain not true for general purpose malloc/free implementations on modern operating systems.
> 
> If you talk to the people who actually do real time software, they don't use malloc/free precisely because they are not deterministic. They preallocate all data.

I'd like to see a standard response on the website along these lines.
Something like:

FAQ:
Q.Isn't GC slow and non-deterministic?
A. Yes, but *all* dynamic memory management is slow and non-deterministic. If you talk to the people who actually do real time software, they don't use malloc/free precisely because they are not deterministic. They preallocate all data.
However, the use of GC instead of malloc enables advanced language constructs (especially, more powerful array syntax), which greatly reduce the number of memory allocations which need to be made.
November 20, 2006
Don Clugston wrote:
> I'd like to see a standard response on the website along these lines.

Done.
November 20, 2006
On Sun, 19 Nov 2006 22:38:46 -0800, Walter Bright <newshound@digitalmars.com> wrote:

> The ones who don't want to use D will find the first excuse, valid or not. Fix the excuse, and they'll just move on to the next excuse, valid or not. It's a fool's game. I've been around that circle before. The people we should listen to are the people who actually *use* D, not the ones who just glanced at a chart looking for fault.
>


You're so right. :(

-JJR
November 20, 2006
> Indeed.  The people who really need to be GC-free are a tiny minority. Wasting a lot of manpower creating a non-GC library just people who don't want to convert from C++ will have one less justification for not using D sees like a huge waste of effort to me.

What about game developers? At least with the current GC, although use of malloc/free isn't strictly deterministic, aren't you far less likely to end up with huge (by game standards, and hence unacceptable) pauses to execution? Preallocation of everything isn't always possible.
November 20, 2006
== Quote from Walter Bright (newshound@digitalmars.com)'s article
> If you talk to the people who actually do real time software, they don't use malloc/free precisely because they are not deterministic. They preallocate all data.

Preallocating all data is a lot of pain. Please consider adding something
to the language that would solve the problem. Some suggestion involve
opAssign and/or implicit casts. Also take a look at my suggestion for value
classes:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=44163

Performance reason: I actually did some benchmarking, comparing
C++ stack allocated classes versus Java classes - C++ was ~30x faster
than Java and Java was ~20x faster than D.

I don't understand why a good RIAA is not already a part of D. C++ has it, so
it obviously can be done. The new 'scoped' keyword is insufficient for me,
because I'd like to make all my classes scoped. I can usually develop
99% of my C++ code without a single 'new' or 'malloc'. Most of my classes
are small (average ~2 fields and ~4 methods) and only used locally, so I'm
really angry when I think about negative performance impact they will have
in D simply because a decent RIAA is missing.
November 20, 2006
Boris Kolar wrote:
> I don't understand why a good RIAA is not already a part of D. C++ has it, so
> it obviously can be done. The new 'scoped' keyword is insufficient for me,
> because I'd like to make all my classes scoped. I can usually develop
> 99% of my C++ code without a single 'new' or 'malloc'. Most of my classes
> are small (average ~2 fields and ~4 methods) and only used locally, so I'm
> really angry when I think about negative performance impact they will have
> in D simply because a decent RIAA is missing.

Have you considered using structs instead of classes? They are allocated on the stack.