One of D's intended uses is systems level programming.  These tasks include implementing ISR (interrupt service routines).  Generally speaking it is a very bad idea to allocate memory within an ISR, unless your memory system is reentrant.  Many memory managers, especially in the embedded environment, are not reentrant.  What language features of D implicitly allocate or resize memory?  I assume dynamic arrays, associative arrays, splicing, and concatenation will, but what else?  Obviously "new" allocates memory, but that is an explicit request by the programmer, not an implicit request as a side effect of a D language feature.  It would be very useful to have the ability to tag a scope of code as "native" or "pure" or "some_better_keyword" so the D compiler would issue an error for any expressions or statements within that scope that implicitly allocate/resized memory.  Thoughts, comments?

Forest

Forest Ray wrote:
> One of D's intended uses is systems level programming.  These tasks include implementing ISR (interrupt service routines).  Generally speaking it is a very bad idea to allocate memory within an ISR, unless your memory system is reentrant.  Many memory managers, especially in the embedded environment, are not reentrant.  What language features of D implicitly allocate or resize memory?  I assume dynamic arrays, associative arrays, splicing, and concatenation will, but what else?  Obviously "new" allocates memory, but that is an explicit request by the programmer, not an implicit request as a side effect of a D language feature.  It would be very useful to have the ability to tag a scope of code as "native" or "pure" or "some_better_keyword" so the D compiler would issue an error for any expressions or statements within that scope that implicitly allocate/resized memory.  Thoughts, comments?
> 
> Forest

'new', concatenation and adding elements to associative arrays allocate memory. Those are the only language features that do (AFAIK)

Of the ones you assumed did, notably splicing does not.

 - Gregor Richards

Well, slicing will not.  Splicing will.  Sorry to be pedantic.

-[Unknown]


> Forest Ray wrote:
>> One of D's intended uses is systems level programming.  These tasks include implementing ISR (interrupt service routines).  Generally speaking it is a very bad idea to allocate memory within an ISR, unless your memory system is reentrant.  Many memory managers, especially in the embedded environment, are not reentrant.  What language features of D implicitly allocate or resize memory?  I assume dynamic arrays, associative arrays, splicing, and concatenation will, but what else?  Obviously "new" allocates memory, but that is an explicit request by the programmer, not an implicit request as a side effect of a D language feature.  It would be very useful to have the ability to tag a scope of code as "native" or "pure" or "some_better_keyword" so the D compiler would issue an error for any expressions or statements within that scope that implicitly allocate/resized memory.  Thoughts, comments?
>>
>> Forest
> 
> 'new', concatenation and adding elements to associative arrays allocate memory. Those are the only language features that do (AFAIK)
> 
> Of the ones you assumed did, notably splicing does not.
> 
>  - Gregor Richards

Unknown W. Brackets wrote:
> Well, slicing will not.  Splicing will.  Sorry to be pedantic.
> 
> -[Unknown]
> 

I stand corrected.

Nae, defeated.

:'(

 - Gregor Richards

PS: For the confused: Slicing is this: someArray[1..3]. Splicing would be, for example: someArray = someArray[0..1] ~ someOtherArray ~ someArray[1..$]

On Sat, 05 May 2007 02:11:08 -0400
Forest Ray <disto@flying-guillotine.com> wrote:

> One of D's intended uses is systems level programming.  These tasks include implementing ISR (interrupt service routines).  Generally speaking it is a very bad idea to allocate memory within an ISR, unless your memory system is reentrant.  Many memory managers, especially in the embedded environment, are not reentrant.  What language features of D implicitly allocate or resize memory?  I assume dynamic arrays, associative arrays, splicing, and concatenation will, but what else?  Obviously "new" allocates memory, but that is an explicit request by the programmer, not an implicit request as a side effect of a D language feature.  It would be very useful to have the ability to tag a scope of code as "native" or "pure" or "some_better_keyword" so the D compiler would issue an error for any expressions or statements within that scope that implicitly allocate/resized memory.  Thoughts, comments?
> 
> Forest

You can use any language features that do not require dynamic memory allocation, as you said already.

The things requiring the GC are:
 - dynamic arrays, associative arrays
 - array slicing when you .dup the slice (I think, at least. If you
don't duplicate the slice, it'll only be a from-to-reference to the
original array)
 - array concatination
 - dynamic class instantiation (new)
 - debug features: always use the -release or -frelease switch, as
there are debug functions added you would have to provide yourself if
you don't link with a runtime library. Also, most of 'em require a GC,
IIRC.

Unfortunately some internal stuffies use these kind of features, too, at times, which means that you have to hack together either a memory manager + GC that is available at compile time, or try to work around that by providing functions which are only statically using memory.

Splicing seems to be concatination? If so, this also requires a GC. Maybe this can be worked around with hacking the internals, too, but that's not recommended.

Kind regards,
Alex

> It would be very useful to have the ability to tag a scope of
> code as "native" or "pure" or "some_better_keyword" so the D compiler
> would issue an error for any expressions or statements within that scope
> that implicitly allocate/resized memory. Thoughts, comments?

I agree, that would be nice.  I think it maybe a bit difficult to do it statically with things like functions that are in other libraries.  I don't think that it's impossible though.

I've used a run-time variant in the past to speed up rendering (it would assert if any memory was allocated during the alloted time.  Perhaps tango could provide a debugging option to assert when allocations are made, or something like that.

-Joel

As others have said, string concatenation (via ~), the .dup property, insertions into AAs (and possibly removals as well), and 'new' calls. Those are the only language features I can think of that allocate.  As for library calls, Tango almost never allocates internally.  This has actually been a source of contention for some, but I think the benefit is worthwhile.


Sean

Sean Kelly schrieb am 2007-05-05:
> As others have said, string concatenation (via ~), the .dup property, insertions into AAs (and possibly removals as well), and 'new' calls. Those are the only language features I can think of that allocate.

Depending on the libary implementation
"foreach(char c; dchar[])" and .sort might heap allocate too.

Thomas

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Sean Kelly schrieb am 2007-05-05:
>> As others have said, string concatenation (via ~), the .dup property, insertions into AAs (and possibly removals as well), and 'new' calls. Those are the only language features I can think of that allocate.
> 
> Depending on the libary implementation
> "foreach(char c; dchar[])" and .sort might heap allocate too.

Good point.  Though neither of these allocate in Phobos/GPhobos (for the record).


Sean