digitalmars.D - Dynamic Sized Stack Frames
- Jonathan Marler (34/34) Nov 17 2013 When the life of a buffer is tied to the life of a function, it
- Chris Cain (7/9) Nov 17 2013 core.stdc.stdlib has "alloca" ... it allocates a runtime
- Jonathan Marler (3/13) Nov 17 2013 Are you serious? It seems the more I learn about D the more
- Mike Parker (4/12) Nov 17 2013 While D is awesome, alloca is actually a standard C function, which is
- dennis luehring (3/16) Nov 18 2013 alloca is not in the C standard - but most compilers implement it - and
When the life of a buffer is tied to the life of a function, it
makes sense to allocate it on the stack because it's much easier
to pop memory off the stack then to garbage collect it later.
For example if had a function that required a buffer to read from
some sort of input, it would make sense to allocate the buffer on
the stack, i.e.
run() {
byte buffer[BUFF_SIZE];
while(running) {
int n = read(buffer, BUFF_SIZE);
...
However, what if I want the size of the buffer to be configurable
at runtime? Maybe this function is part of some sort of library
that allows the user to specify a smaller or larger buffer to
optimize the number of read calls. As far as I know, in order
for a library to have a buffer whose length isn't known until
runtime, it would require allocating it on the heap. Then we
have a buffer that is only needed for the life of this function
but still needs to be garbage collected. The solution I came up
with for this type of scenario is what I am calling "dynamic
sized stack frames". The buffer could be allocated on the stack,
and the length of the buffer could be pushed on the stack as well
so the function can properly clean it when it returns. I don't
know of any languages that support this type of functionality,
does anyone know if there is one? Maybe this is a new feature
that D could introduce in a later version?
As far as implementation there's a couple of ways this could be
done...the caller could allocate the buffer, or the caller could
just push the buffer length as an extra parameter and the callee
could be solely responsible for allocating the buffer and
cleaning it up afterwards (as I'm writing this that sounds like a
safer option). Anyway I wanted to put this idea out there and
see what people's thoughts are. Thanks in advance for any
helpful opinions or criticism.
Nov 17 2013
On Monday, 18 November 2013 at 05:46:48 UTC, Jonathan Marler wrote:However, what if I want the size of the buffer to be configurable at runtime?core.stdc.stdlib has "alloca" ... it allocates a runtime configurable amount of memory on the stack. There's a few threads on doing some tricks with it. For instance, if you use it as a default parameter, then it'll allocate on the caller's stack so you can actually return a ref to it from the function :)
Nov 17 2013
On Monday, 18 November 2013 at 05:58:25 UTC, Chris Cain wrote:On Monday, 18 November 2013 at 05:46:48 UTC, Jonathan Marler wrote:Are you serious? It seems the more I learn about D the more impressed I become. Thanks for the quick response :)However, what if I want the size of the buffer to be configurable at runtime?core.stdc.stdlib has "alloca" ... it allocates a runtime configurable amount of memory on the stack. There's a few threads on doing some tricks with it. For instance, if you use it as a default parameter, then it'll allocate on the caller's stack so you can actually return a ref to it from the function :)
Nov 17 2013
On 11/18/2013 3:03 PM, Jonathan Marler wrote:On Monday, 18 November 2013 at 05:58:25 UTC, Chris Cain wrote:While D is awesome, alloca is actually a standard C function, which is why it's in the core.stdc.stdlib package. You have full access to the C standard library from D.core.stdc.stdlib has "alloca" ... it allocates a runtime configurable amount of memory on the stack. There's a few threads on doing some tricks with it. For instance, if you use it as a default parameter, then it'll allocate on the caller's stack so you can actually return a ref to it from the function :)Are you serious? It seems the more I learn about D the more impressed I become. Thanks for the quick response :)
Nov 17 2013
Am 18.11.2013 08:31, schrieb Mike Parker:On 11/18/2013 3:03 PM, Jonathan Marler wrote:alloca is not in the C standard - but most compilers implement it - and its not a regular functions cause its reserves space on stackOn Monday, 18 November 2013 at 05:58:25 UTC, Chris Cain wrote:While D is awesome, alloca is actually a standard C function, which is why it's in the core.stdc.stdlib package. You have full access to the C standard library from D.core.stdc.stdlib has "alloca" ... it allocates a runtime configurable amount of memory on the stack. There's a few threads on doing some tricks with it. For instance, if you use it as a default parameter, then it'll allocate on the caller's stack so you can actually return a ref to it from the function :)Are you serious? It seems the more I learn about D the more impressed I become. Thanks for the quick response :)
Nov 18 2013








dennis luehring <dl.soluz gmx.net>