Re: dynamically allocating on the stack
On Sunday, 22 April 2018 at 00:41:34 UTC, Nicholas Wilson wrote: You're not using the C library version of it, the compiler does the stack space reservation inline for you. There is no way around this. I'm not convinced. I did some no-runtime testing and eventually found the implementation in druntime here: https://github.com/dlang/druntime/blob/master/src/rt/alloca.d Mike
Re: dynamically allocating on the stack
On Sunday, April 22, 2018 01:07:44 Giles Bathgate via Digitalmars-d-learn wrote: > On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer > > wrote: > > alloca is an intrinsic, and part of the language technically -- > > it has to be. > > Why does: > > scope c = new C(); // allocate c on stack > scope a = new char[len]; // allocate a via gc? Because prior to DIP 1000 being introduced, scope did absolutely nothing to parameters if they weren't delegates, and it did nothing to other variables if they weren't classes. So, without -dip1000, scope is ignored on the second line. scope on parameters was to tell the compiler that the delegate didn't escape so that it didn't have to allocate a closer. scope on classes was to force them to be allocated on the stack and have a deterministic lifetime, since classes normally live on the heap. Without -dip1000, it's completely unsafe to do, because the compiler makes no guarantees about references to the class not escaping, which is why std.typecons.scoped was introduced to replace it, and scope on classes was going to be deprecated. However, when Walter was looking into improving @safety with ref and adding some sort of ref-counting mechanism into the language, he found that he needed better guarantees about the lifetime of some objects in @safe code in order to be able to guarantee @safety. So, he came up with DIP 1000, which expands scope to do a lot more. The result is that scope has been greatly expanded with DIP 1000 and its meaning has subtly changed. It becomes closer to what it meant for parameters that were delegates in that it makes guarantees about no references or pointers or whatnot to an object escaping the scope. The effect on classes is then retained, but it becomes an optimization that the compiler can do as a result of what scope allows it to guarantee rather than an instruction by the programmer to tell the compiler to put the object on the stack. As such, the optimization could theoretically be expanded to affect any call to new where the result is assigned to variable that's marked with scope rather than just classes, but I don't think that it has been yet. Also, because scope is then forced to be used in enough places to allow the compiler to make guarantees about the lifetime of the object and not allow it to escape, the @safety issues with scope on classes is fixed, which more or less negates the need for std.typecons.scoped, and the deprecation for scope on classes has therefore been nixed. However, unless -dip1000, the only status quo is still in effect, making scope on classes very much unsafe, and until -dip1000 is the default behavior (which will probably be a while), we really can't take advantage of the improvements that it's supposed to provide (and currently, because -dip1000 makes ABI-incompatible changes, you have to have compiled your entire software stack - Phobos included - with -dip1000 to use it, meaning that it's mostly unusable right now). - Jonathan M Davis
Re: How to use std.meta.Filter?
On 4/21/18 1:46 PM, Dr.No wrote:
On Saturday, 21 April 2018 at 17:15:47 UTC, Jonathan M Davis wrote:
On Saturday, April 21, 2018 16:05:22 Dr.No via Digitalmars-d-learn wrote:
import std.meta : Filter;
enum isNotReservedSymbol(string name) = name != "none" && name !=
"lastToken";
enum string[] members = staticMembers!Token;
static foreach(member; Filter!(isNotReservedSymbol, members))
{{
This return the error:
Error: template instance `pred!(["none", "word", "n", "digits",
"name", /* my whole array here */ ]) does not match template
declaration isNotReservedSymbol(string name)
how should have isNotReservedSymbol be defined?
std.meta.Filter operates on an AliasSeq, not a dynamic array. If you
have an array, then you can just use std.algorithm.iteration.filter
with a normal lambda.
I've tried use normal filter - albeit i'm willing to do all that at
runtin, but I got f cannot be read at compile time.
static foreach(member; staticMembers!Token.filter!(f =>
isNotReservedSymbol!(member))
Filter probably should work on arrays readable at compile time. I bet it
just hasn't been updated since static foreach was introduced.
-Steve
Re: dynamically allocating on the stack
On 4/21/18 7:47 PM, Mike Franklin wrote: On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it). Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations. Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D. As Nick says, it's an intrinsic. The call never gets to the C library. And it can't anyway -- if you give it some thought, you will realize, there's no way for a function to add stack space in the calling function. The compiler has to deal with that new space somehow, and make sure it puts it in the right place. So you don't need a C library. I frankly don't know why it's in core.stdc, except maybe to be consistent with C? -Steve
Re: How to use std.meta.Filter?
On Saturday, 21 April 2018 at 17:46:05 UTC, Dr.No wrote:
On Saturday, 21 April 2018 at 17:15:47 UTC, Jonathan M Davis
wrote:
On Saturday, April 21, 2018 16:05:22 Dr.No via
Digitalmars-d-learn wrote:
import std.meta : Filter;
enum isNotReservedSymbol(string name) = name != "none" &&
name !=
"lastToken";
enum string[] members = staticMembers!Token;
static foreach(member; Filter!(isNotReservedSymbol, members))
{{
This return the error:
Error: template instance `pred!(["none", "word", "n",
"digits",
"name", /* my whole array here */ ]) does not match template
declaration isNotReservedSymbol(string name)
how should have isNotReservedSymbol be defined?
std.meta.Filter operates on an AliasSeq, not a dynamic array.
If you have an array, then you can just use
std.algorithm.iteration.filter with a normal lambda.
- Jonathan M Davis
I've tried use normal filter - albeit i'm willing to do all
that at runtin, but I got f cannot be read at compile time.
static foreach(member; staticMembers!Token.filter!(f =>
isNotReservedSymbol!(member))
If you are confused by why some things work during compilation
and others don't, I would encourage you to read
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
Its a nice article explaining how there are two "compile-time"
steps where code can be executed.
ldc flags for beginner
what flags to use so that the intermediate .o files are discared by ldc and only a.out is written to disk
Re: dynamically allocating on the stack
On Sunday, 22 April 2018 at 01:26:09 UTC, Uknown wrote: Its a special case for classes. Makes them usable without the GC. The intention was actually just to have deterministic destruction - a scope class ctor runs at the end of scope (and it used to be you could force a class to always be scope too). The stack allocation is simply an optimization enabled by the scope lifetime. That optimization can apply elsewhere too.
Re: dynamically allocating on the stack
On Sunday, 22 April 2018 at 01:07:44 UTC, Giles Bathgate wrote: On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. Why does: scope c = new C(); // allocate c on stack scope a = new char[len]; // allocate a via gc? Its a special case for classes. Makes them usable without the GC.
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. Why does: scope c = new C(); // allocate c on stack scope a = new char[len]; // allocate a via gc?
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 23:47:41 UTC, Mike Franklin wrote: On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it). Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations. Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D. Mike As you have discovered alloca is a builtin: this is true for LDC, GDC and DMD, it's true for clang and i suspect most C/C++ compilers. You're not using the C library version of it, the compiler does the stack space reservation inline for you. There is no way around this. Use `std.experimental.allocator.building_blocks.Region` with a slice from `alloca`. or if you just want the memory scope T[] arr = (cast(T*)alloca(n*T.sizeof))[0 .. n];
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it). Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations. Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D. Mike
Re: Getting the overload set of a template
On Saturday, 21 April 2018 at 19:51:05 UTC, Simen Kjærås wrote:
On Saturday, 21 April 2018 at 11:23:33 UTC, Alex wrote:
So, do you mean, that the constraint belongs to the interface
of a template?
Not necessarily - it depends on what you want to achieve. The
only thing I mean is that the code clearly defines two
templates in one case (and chooses which template to
instantiate based on the arguments), and one template in the
other (and chooses the contents of that template based on the
arguments).
This is wrong, at least as I understand this:
Lowering rules apply. These rules define a set of semantic
equivalent constructs. I expect all semantic equivalent
constructs to be handled equivalent.**
Sure, the end result may be similar*, but how it works in the
language is clearly defined, and different between the two
cases.
*In this case, there are important differences - in the first
case the template itself is marked with a UDA, in the second
the enum member is.
This is a good point. But you won't be able to get the UDA from
an uninstantiated template will you? If you will, then, I'm
wrong, I think...
** So my point is: If you can transform some construct into
another one by lowering rules, than
- either: you can't define an overload
- or: you can define same overloads on both forms.
[1]
In the first case foo!"c" will fail to instantiate, in the
second it won't.
This is due, I didn't add
´´´
else
{
assert(0);
}
´´´
sorry for this.
[1]
http://www.drdobbs.com/architecture-and-design/so-you-want-to-write-your-own-language/240165488?pgno=2
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 14:25:58 UTC, Cym13 wrote: On Saturday, 21 April 2018 at 13:54:14 UTC, H. S. Teoh wrote: On Sat, Apr 21, 2018 at 01:30:55PM +, Cym13 via Digitalmars-d-learn wrote: On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote: [...] > Unbounded allocation on stack is kind of anti-pattern and a > potential DoS vector. I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector. [...] Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow. Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input. T Wait, why? Don't they share the same address space and grow in opposite directions? That was true more like 25 years ago. Same address space is obviously still true. These days heap is usually not using sbrk which is basically what you describe. Also imagine threads and tell me which stack grows towards which ;) Heap is allocated with mmap on Posix’es and VirtualAlloc on Windows. Stack is typically fixed limit imposed by ulimit and how it grows is beside the point really.
Re: Getting the overload set of a template
On Saturday, 21 April 2018 at 11:23:33 UTC, Alex wrote: On Thursday, 19 April 2018 at 17:55:47 UTC, Simen Kjærås wrote: Your first example defines two templates (which are overloads of the same name), the second only one. There's no ambiguity there. So, do you mean, that the constraint belongs to the interface of a template? Not necessarily - it depends on what you want to achieve. The only thing I mean is that the code clearly defines two templates in one case (and chooses which template to instantiate based on the arguments), and one template in the other (and chooses the contents of that template based on the arguments). Sure, the end result may be similar*, but how it works in the language is clearly defined, and different between the two cases. *In this case, there are important differences - in the first case the template itself is marked with a UDA, in the second the enum member is. In the first case foo!"c" will fail to instantiate, in the second it won't. -- Simen
Re: dynamically allocating on the stack
On 4/21/18 3:57 AM, Uknown wrote:
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
The language itself doesn't have something, but you could use `alloca`:
alloca is an intrinsic, and part of the language technically -- it has
to be.
Mike, alloca is what you are looking for.
-Steve
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 13:30:55 UTC, Cym13 wrote:
On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky
wrote:
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin
wrote:
Does D have some way to dynamically allocate on the stack?
I'm looking for something roughly equivalent to the following
C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Unbounded allocation on stack is kind of anti-pattern and a
potential DoS vector.
I'm having trouble seeing how unbounded heap allocations aren't
equally a potential DoS vector.
I could see what you meant, but really stack is typically far
more limited then heap in size.
Unless you tune the stack size yourself (i.e. you both build an
app and control the environment) there is no sensible way to know
the size you can use. It’s also heavily platform dependent.
With heap it’s usually far less limited resource.
Lastly Fibers usually have small stacks.
A separate region allocator is exactly as fast and can easily
survive across boundaries of function calls.
I guess if OP wants it on the stack it's because it doesn't
need to survive across boundaries of function calls so this
buys nothing in this case.
Yet nothing to lose and much safer bet in general.
In general, I’d expect performance to be the goal here. If so
then zone/region allocation is a well known pattern that is not
restricted to individual arrays and is widely used in games and
industry-grade stuff like browsers/VMs.
Also you probably want something like char[X] = void;
for efficiency if allocating on stack.
Thanks,
Mike
Advice on : rmdirRecurse and setAttributes in Windows
Hi All,
The function rmdirRecurse does not work in Windows if the file
has the READ ONLY permission, so to over come this issue, i have
written the below function to set the permission on file and
folder using the function "setAttributes" , so can any one advice
me whether the below code is fine or what are the other ways to
achieve the same.
auto aPrivileges(T)(T df)
if(df[0].isDir) {
auto sDir = Array!string(dirEntries(join([`\\?\`,
df[0]]), SpanMode.depth).filter!(a => a.isDir).map!(a =>
(a.name)));
auto sFile = Array!string(dirEntries(join([`\\?\`,
df[0]]), SpanMode.depth).filter!(a => a.isFile).map!(a =>
(a.name)));
foreach(sD; parallel(sDir[], 1)) {
setAttributes(sD.toUTF16, 66); }
foreach(sF; parallel(sFile[], 1)) {
setAttributes(sF.toUTF16, 666); }
}
else { setAttributes(df[0].toUTF16, 666); }
}
From,
Vino.B
Re: How to use std.meta.Filter?
On Saturday, April 21, 2018 17:46:05 Dr.No via Digitalmars-d-learn wrote:
> On Saturday, 21 April 2018 at 17:15:47 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, April 21, 2018 16:05:22 Dr.No via
> >
> > Digitalmars-d-learn wrote:
> >> import std.meta : Filter;
> >> enum isNotReservedSymbol(string name) = name != "none" && name
> >> !=
> >> "lastToken";
> >> enum string[] members = staticMembers!Token;
> >> static foreach(member; Filter!(isNotReservedSymbol, members))
> >> {{
> >>
> >> This return the error:
> >> Error: template instance `pred!(["none", "word", "n",
> >>
> >> "digits",
> >> "name", /* my whole array here */ ]) does not match template
> >> declaration isNotReservedSymbol(string name)
> >>
> >> how should have isNotReservedSymbol be defined?
> >
> > std.meta.Filter operates on an AliasSeq, not a dynamic array.
> > If you have an array, then you can just use
> > std.algorithm.iteration.filter with a normal lambda.
> >
> > - Jonathan M Davis
>
> I've tried use normal filter - albeit i'm willing to do all that
> at runtin, but I got f cannot be read at compile time.
>
> static foreach(member; staticMembers!Token.filter!(f =>
> isNotReservedSymbol!(member))
Well, it would help if you actually provide an example that I could compile.
Based on what you've posted thus far, I assume that staticMembers!Token
results in a dynamic array of strings. So, if I have
import std.algorithm.iteration : filter;
enum names = ["none", "word", "n", "digits", "name"];
enum isNotReservedSymbol(string name) = name != "none" &&
name != "lastToken";
static foreach(member; names.filter!(f => isNotReservedSymbol!member))
{
}
void main()
{
}
then I have something similar to what you have, and I get the error
q.d(7): Error: undefined identifier member
/usr/local/include/dmd/std/algorithm/iteration.d(1106):instantiated
from here: FilterResult!(__lambda6, string[])
q.d(7):instantiated from here: filter!(string[])
The problem with this is that member is being used on both the left and the
right of the foreach. You can't use the iteration variable in what you're
iterating. So, I'm guessing that you really meant to use f on the right-hand
side of the lambda. In that case, it's
static foreach(member; names.filter!(f => isNotReservedSymbol!f))
{
}
and the error message becomes
q.d(7): Error: variable f cannot be read at compile time
q.d(7):while looking for match for isNotReservedSymbol!(f)
/usr/local/include/dmd/std/algorithm/iteration.d(1106):instantiated
from here: FilterResult!(__lambda6, string[])
q.d(7):instantiated from here: filter!(string[])
And that error message is more like what you mentioned, so I'm guessing that
this is what you're hitting. The problem here is that you're mixing up
runtime and compile-time constructs. Even though all of this is happening at
compile time, there's a difference between a purely compile-time construct
and a runtime construct that's run during CTFE. e.g. something like
bool foo(string str)
{
return isNotReservedSymbol!str;
}
cannot compile, becuase str is a runtime parameter and thus its value is
only known at runtime, whereas isNotReservedSymbol is a template, so its
argument must be known during compile time - i.e. when the functions is
compiled. Using foo with CTFE doesn't change that. foo still needs to
compile as if it were going to be used at runtime. The resulting function
can then be used at compile time, but it needs to be compiled first. Your
lambda has the same problem. Generally, the two options in a case like this
are to either turn the parameter into a compile-time parameter or to use a
function instead of a template. e.g.
bool foo(string str)()
{
return isNotReservedSymbol!str;
}
or
bool isNotReservedSymbol(string name)
{
return name != "none" && name != "lastToken";
}
bool foo(string str)
{
return isNotReservedSymbol(str);
}
Given that you're operating on a dynamic array of strings, there's really no
reason to declare templates to operate on it. Stuff like std.meta.Filter is
for cases where you need to use an AliasSeq, which _usually_ means that
you're dealing with actual symbols and not values (occasionally, it can make
sense to use an AliasSeq with values, but that's usually only if they're not
the same type or if the AliasSeq contains a mix of types and values, since
if an AliasSeq containts values of the same type, you can always just put []
around the AliasSeq to get a dynamic array of its values). So, I'd suggest
that you simply make isNotReservedSymbol a function. And then you get
something like
import std.algorithm.iteration : filter;
enum names = ["none", "word", "n", "digits", "name"];
bool isNotReservedSymbol(string name)
{
return name != "none" && name != "lastToken";
}
static foreach(member; names.filter!(f => isNotReservedSymbol(f)))
{
}
void main()
{
}
and that compiles.
- Jonathan M Davis
Re: How to use std.meta.Filter?
On Saturday, 21 April 2018 at 17:15:47 UTC, Jonathan M Davis
wrote:
On Saturday, April 21, 2018 16:05:22 Dr.No via
Digitalmars-d-learn wrote:
import std.meta : Filter;
enum isNotReservedSymbol(string name) = name != "none" && name
!=
"lastToken";
enum string[] members = staticMembers!Token;
static foreach(member; Filter!(isNotReservedSymbol, members))
{{
This return the error:
Error: template instance `pred!(["none", "word", "n",
"digits",
"name", /* my whole array here */ ]) does not match template
declaration isNotReservedSymbol(string name)
how should have isNotReservedSymbol be defined?
std.meta.Filter operates on an AliasSeq, not a dynamic array.
If you have an array, then you can just use
std.algorithm.iteration.filter with a normal lambda.
- Jonathan M Davis
I've tried use normal filter - albeit i'm willing to do all that
at runtin, but I got f cannot be read at compile time.
static foreach(member; staticMembers!Token.filter!(f =>
isNotReservedSymbol!(member))
Re: How to use std.meta.Filter?
On Saturday, April 21, 2018 16:05:22 Dr.No via Digitalmars-d-learn wrote:
> import std.meta : Filter;
> enum isNotReservedSymbol(string name) = name != "none" && name !=
> "lastToken";
> enum string[] members = staticMembers!Token;
> static foreach(member; Filter!(isNotReservedSymbol, members))
> {{
>
>
> This return the error:
>
> Error: template instance `pred!(["none", "word", "n", "digits",
> "name", /* my whole array here */ ]) does not match template
> declaration isNotReservedSymbol(string name)
>
> how should have isNotReservedSymbol be defined?
std.meta.Filter operates on an AliasSeq, not a dynamic array. If you have an
array, then you can just use std.algorithm.iteration.filter with a normal
lambda.
- Jonathan M Davis
How to use std.meta.Filter?
import std.meta : Filter;
enum isNotReservedSymbol(string name) = name != "none" && name !=
"lastToken";
enum string[] members = staticMembers!Token;
static foreach(member; Filter!(isNotReservedSymbol, members))
{{
This return the error:
Error: template instance `pred!(["none", "word", "n", "digits",
"name", /* my whole array here */ ]) does not match template
declaration isNotReservedSymbol(string name)
how should have isNotReservedSymbol be defined?
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 13:30:55 UTC, Cym13 wrote: [...] Nevermind, forgot that shared libraries are put between the two.
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 13:54:14 UTC, H. S. Teoh wrote: On Sat, Apr 21, 2018 at 01:30:55PM +, Cym13 via Digitalmars-d-learn wrote: On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote: [...] > Unbounded allocation on stack is kind of anti-pattern and a > potential DoS vector. I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector. [...] Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow. Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input. T Wait, why? Don't they share the same address space and grow in opposite directions?
Re: dynamically allocating on the stack
On Sat, Apr 21, 2018 at 01:30:55PM +, Cym13 via Digitalmars-d-learn wrote: > On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote: [...] > > Unbounded allocation on stack is kind of anti-pattern and a > > potential DoS vector. > > I'm having trouble seeing how unbounded heap allocations aren't > equally a potential DoS vector. [...] Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow. Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input. T -- My program has no bugs! Only unintentional features...
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky
wrote:
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack?
I'm looking for something roughly equivalent to the following
C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Unbounded allocation on stack is kind of anti-pattern and a
potential DoS vector.
I'm having trouble seeing how unbounded heap allocations aren't
equally a potential DoS vector.
A separate region allocator is exactly as fast and can easily
survive across boundaries of function calls.
I guess if OP wants it on the stack it's because it doesn't need
to survive across boundaries of function calls so this buys
nothing in this case.
Also you probably want something like char[X] = void;
for efficiency if allocating on stack.
Thanks,
Mike
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C
code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Unbounded allocation on stack is kind of anti-pattern and a
potential DoS vector.
A separate region allocator is exactly as fast and can easily
survive across boundaries of function calls.
Also you probably want something like char[X] = void;
for efficiency if allocating on stack.
Thanks,
Mike
Re: Getting the overload set of a template
On Thursday, 19 April 2018 at 17:55:47 UTC, Simen Kjærås wrote: Your first example defines two templates (which are overloads of the same name), the second only one. There's no ambiguity there. So, do you mean, that the constraint belongs to the interface of a template?
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 10:47:47 UTC, Timon Gehr wrote: That does not work (you are returning a dangling reference into the stack of the function that is returning). Yeah I had hoped that the pragma(inline, true) would solve that, but it dosesn't :(
Re: dynamically allocating on the stack
On 21.04.2018 12:08, Giles Bathgate wrote:
On Saturday, 21 April 2018 at 07:57:41 UTC, Uknown wrote:
The language itself doesn't have something, but you could use `alloca`
I don't know if this little template function makes life easier:
--
pragma(inline, true)
ref T push(T)(size_t len)
{
import core.stdc.stdlib, core.stdc.stdio;
return *cast(T*)alloca(T.sizeof * len);
}
void doSomething(size_t len)
{
auto stackBuffer = push!char(len+1);
stackBuffer[0] = 'H';
stackBuffer[1] = '\0';
printf("%.*s", stackBuffer.ptr);
}
void main()
{
doSomething(2);
}
--
That does not work (you are returning a dangling reference into the
stack of the function that is returning). You could do this:
import core.stdc.stdlib, core.stdc.stdio;
auto push(T,alias len)(T[] mem=(cast(T*)alloca(T.sizeof*len))[0..len]){
return mem; // (uninitialized!)
}
void doSomething(size_t len){
char[] stackBuffer=push!(char,len);
stackBuffer[0] = 'H';
stackBuffer[1] = '\0';
printf("%s", stackBuffer.ptr);
}
void main(){
doSomething(2);
}
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C
code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
https://issues.dlang.org/show_bug.cgi?id=18788
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 10:08:43 UTC, Giles Bathgate wrote: I don't know if this little template function makes life easier: Sorry, that doesn't work at all.
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:57:41 UTC, Uknown wrote:
The language itself doesn't have something, but you could use
`alloca`
I don't know if this little template function makes life easier:
--
pragma(inline, true)
ref T push(T)(size_t len)
{
import core.stdc.stdlib, core.stdc.stdio;
return *cast(T*)alloca(T.sizeof * len);
}
void doSomething(size_t len)
{
auto stackBuffer = push!char(len+1);
stackBuffer[0] = 'H';
stackBuffer[1] = '\0';
printf("%.*s", stackBuffer.ptr);
}
void main()
{
doSomething(2);
}
--
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:57:41 UTC, Uknown wrote:
The language itself doesn't have something.
It would be cool if you could just do
int doSomething(size_t len)
{
char stackBuffer = push char[len + 1];
doSomethingElse(stackBuffer);
}
i.e some kind of `push` keyword instead of `new` perhaps its too
much of an edge case.
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C
code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Thanks,
Mike
The language itself doesn't have something, but you could use
`alloca`:
---
void doSomething(size_t len)
{
import core.stdc.stdlib, core.stdc.stdio;
auto stackBuffer = (cast(char*) alloca(char.sizeof * len +
1))[0 .. len + 1];
stackBuffer[0] = 'H';
stackBuffer[1] = '\0';
printf("%.*s", stackBuffer.ptr);
}
void main()
{
doSomething(2);
}
---
dynamically allocating on the stack
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Thanks,
Mike
