How can D become adopted at my company?

SomeDude lovelydear at mailmetrash.com
Sat Apr 28 02:35:19 PDT 2012


On Saturday, 28 April 2012 at 09:22:35 UTC, Jonathan M Davis 
wrote:
> On Saturday, April 28, 2012 11:12:21 SomeDude wrote:
>> Real time guarantees on a GC is not something we are going to
>> offer anytime soon anyway. While a minimal library, loosely 
>> based
>> on the C standard library, with some more bells and whistles 
>> that
>> could be borrowed from Phobos, this is a goal that is 
>> achievable
>> in a foreseeable future. And both game developers and embedded
>> programmers would be interested.
>
> If what you want is the C standard library, then use the C 
> standard library.
> There's nothing stopping you, and trying to replicate it in D 
> would be
> pointless.
>
> The main problems with the GC in Phobos are likely arrays and 
> containers. You
> can't fix the array problem. If you do _anything_ which 
> involves slicing or any
> array functions which could allocate, you're going to need the 
> GC. The only
> way to avoid the problem completely is to restrict the 
> functions that you use
> with arrays to those which won't append to an array or 
> otherwise allocate
> memory for an array. The container problem should be resolved 
> via custom
> allocators once they've been added. The custom allocators will 
> also help
> reduce GC issues for classes in general.
>
> But in general, by minimizing how much you do which would 
> require the GC, the
> little that does shouldn't be a big deal. Still, due to how 
> arrays work,
> there's really no way to get away from the GC completely 
> without restricting
> what you do with them, which in some cases means not using 
> Phobos. I don't
> think that there's really any way around that.
>
> - Jonathan M Davis

Right, I understand the situation better now. So basically, 
what's needed is the custom allocators, and the GC would be 
relieved from much of the work. That would still not work for 
hard real time embedded, but for those applications, there are 
lots of restrictions on memory anyway (no dynamic allocation for 
once), so it wouldn't change much.



More information about the Digitalmars-d mailing list