On 21 October 2013 11:48, Walter Bright <newshound2@digitalmars.com> wrote:

> On 10/20/2013 5:59 PM, Jonathan M Davis wrote:
>
>> If that paradigm is frequent enough, it might be worth wrapping it in a struct. Then, you'd probably get something like
>>
>> StaticArray!(int, 10) tmp(n);
>> int[] a = tmp[];
>>
>> which used T[10] if n was 10 or less and allocated T[] otherwise. The destructor could then deal with freeing the memory.
>>
>
> Sounds like a good idea - and it should fit in with Andrei's nascent allocator design.
>

I use this pattern all over the place.
I don't love it though. It doesn't feel elegant at all and it wastes stack
space, but it's acceptable, and I'd really like to see this pattern
throughout phobos, especially where strings and paths are concerned.
System interface functions that pass zero-terminated strings through to the
OS are the primary offender, needless garbage, those should be on the stack.

I like to use alloca too where it's appropriate. I'd definitely like if D
had a variable-sized static array syntax for pretty-ing alloca.
I thought about something similar using alloca via a mixin template, but
that feels really hackey!

21.10.2013 14:30, Manu пишет:
> System interface functions that pass zero-terminated strings through to
> the OS are the primary offender, needless garbage, those should be on
> the stack.
>
> I like to use alloca too where it's appropriate. I'd definitely like if
> D had a variable-sized static array syntax for pretty-ing alloca.
> I thought about something similar using alloca via a mixin template, but
> that feels really hackey!

No hacks needed. See `unstd.c.string` module from previous post:
http://forum.dlang.org/thread/lqdktyndevxfcewgthcj@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Monday, 21 October 2013 at 00:59:38 UTC, Jonathan M Davis wrote:
> On Sunday, October 20, 2013 09:33:36 Walter Bright wrote:
>> On 10/20/2013 7:25 AM, bearophile wrote:
>> > More discussions about variable-sized stack-allocated arrays in C++, it
>> > seems there is no yet a consensus:
>> > 
>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>> > 
>> > I'd like variable-sized stack-allocated arrays in D.
>> 
>> They're far more trouble than they're worth.
>> 
>> Just use:
>> 
>>      auto a = new T[n];
>> 
>> Stack allocated arrays are far more trouble than they're worth. But what
>> about efficiency? Here's what I often do something along the lines of:
>> 
>>      T[10] tmp;
>>      T[] a;
>>      if (n <= 10)
>> 	a = tmp[0..n];
>>      else
>> 	a = new T[n];
>>      scope (exit) if (a != tmp) delete a;
>> 
>> The size of the static array is selected so the dynamic allocation is almost
>> never necessary.
>
> If that paradigm is frequent enough, it might be worth wrapping it in a
> struct. Then, you'd probably get something like
>
> StaticArray!(int, 10) tmp(n);
> int[] a = tmp[];
>
> which used T[10] if n was 10 or less and allocated T[] otherwise. The
> destructor could then deal with freeing the memory.
>
> - Jonathan M Davis

Well that's the approach taken by std::array (C++11), if I am not mistaken.

--
Paulo

On 21 October 2013 21:24, Denis Shelomovskij <verylonglogin.reg@gmail.com>wrote:

> 21.10.2013 14:30, Manu пишет:
>
>  System interface functions that pass zero-terminated strings through to
>> the OS are the primary offender, needless garbage, those should be on the stack.
>>
>> I like to use alloca too where it's appropriate. I'd definitely like if
>> D had a variable-sized static array syntax for pretty-ing alloca.
>> I thought about something similar using alloca via a mixin template, but
>> that feels really hackey!
>>
>
> No hacks needed. See `unstd.c.string` module from previous post:
> http://forum.dlang.org/thread/**lqdktyndevxfcewgthcj@forum.**
> dlang.org?page=2#post-l42evp:**241ok7:241:40digitalmars.com<http://forum.dlang.org/thread/lqdktyndevxfcewgthcj@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com>


Super awesome! Phobos devs should be encouraged to use these in non-recursive functions (particularly OS pass-through's).

Am 21.10.2013 15:04, schrieb Manu:
> On 21 October 2013 21:24, Denis Shelomovskij <verylonglogin.reg@gmail.com>wrote:
>
>> 21.10.2013 14:30, Manu пОшет:
>>
>>  System interface functions that pass zero-terminated strings through to
>>> the OS are the primary offender, needless garbage, those should be on
>>> the stack.
>>>
>>> I like to use alloca too where it's appropriate. I'd definitely like if
>>> D had a variable-sized static array syntax for pretty-ing alloca.
>>> I thought about something similar using alloca via a mixin template, but
>>> that feels really hackey!
>>>
>>
>> No hacks needed. See `unstd.c.string` module from previous post:
>> http://forum.dlang.org/thread/**lqdktyndevxfcewgthcj@forum.**
>> dlang.org?page=2#post-l42evp:**241ok7:241:40digitalmars.com<http://forum.dlang.org/thread/lqdktyndevxfcewgthcj@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com>
>
>
> Super awesome! Phobos devs should be encouraged to use these in
> non-recursive functions (particularly OS pass-through's).
>


looks like Walters solution - but cleaner

"...Implementation note:
For small strings  tempCString will use stack allocated buffer, for large strings (approximately 1000 characters and more) it will allocate temporary one from unstd.memory.allocation.threadHeap..."

does that mean that tempCString reserves minimum 1000 bytes on stack
else using heap?

if so i would prefer a template based version where i can put in the size

21.10.2013 18:04, dennis luehring пишет:
> "...Implementation note:
> For small strings  tempCString will use stack allocated buffer, for
> large strings (approximately 1000 characters and more) it will allocate
> temporary one from unstd.memory.allocation.threadHeap..."
>
> does that mean that tempCString reserves minimum 1000 bytes on stack
> else using heap?
>
> if so i would prefer a template based version where i can put in the size

Yes, `tempCString` allocates `1024 * To.sizeof` bytes on the stack. Note that it doesn't initialize the data so it is O(1) operation which will just do ~1 KiB move of stack pointer. As function stack frame can easily eat 50-100 bytes it is like 10-20 function calls. IIRC typical stack size is ~1 MiB and `tempCString` isn't expected to be used in some deep recursion or be ~1000 times used in one function.

So I'd prefer to change default stack allocation size if needed and not confuse user with manual choice.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On 20 October 2013 20:15, David Nadlinger <code@klickverbot.at> wrote:
> On Sunday, 20 October 2013 at 18:42:06 UTC, Walter Bright wrote:
>>
>> If your optimizing compiler is that good, it can optimize "new T[n]" to be on the stack as well.
>
>
> Just a side note: LDC actually does this if it can prove statically that the size is bounded. Unfortunately, the range detection is rather conservative (unless your allocation size turns out to be a constant due to inlining, LLVM is unlikely to get it).
>
> One idea that might be interesting to think about is to insert a run-time check for the size if an allocation is known not to be escaped, but the size is not yet determined. As a GC allocation is very expensive anyway, this probably wouldn't even be much of a pessimization in the general case.
>

David, can you check the code generation of:

http://dpaste.dzfl.pl/3e333df6


PS:  Walter, looks the above causes an ICE in DMD?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 21 October 2013 at 15:26:33 UTC, Denis Shelomovskij wrote:
>
> So I'd prefer to change default stack allocation size if needed and not confuse user with manual choice.

Wouldn't it work to make it optional then?  Something like this, I think:
auto tempCString(To = char, From, Length = 1024)(in From[] str) if (isSomeChar!To && isSomeChar!From);

Choosing a sane default but allowing specialist users an easy way to fine-tune it for their needs while keeping the basic usage simple is something I'd advocate for.  (Personally, I think 1K sounds quite high; I'd probably make it 256 (one less than the max length of filenames on a whole bunch of filesystems)).

-Wyatt

On 10/21/2013 9:24 AM, Iain Buclaw wrote:
> http://dpaste.dzfl.pl/3e333df6
>
> PS:  Walter, looks the above causes an ICE in DMD?

All ICE's should be filed in bugzilla:

http://d.puremagic.com/issues/show_bug.cgi?id=11315

On 21 October 2013 18:42, Walter Bright <newshound2@digitalmars.com> wrote:
> On 10/21/2013 9:24 AM, Iain Buclaw wrote:
>>
>> http://dpaste.dzfl.pl/3e333df6
>>
>> PS:  Walter, looks the above causes an ICE in DMD?
>
>
> All ICE's should be filed in bugzilla:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11315
>

I've told enough people to raise bugs in GDC to know this.  My intention wasn't to find a bug in DMD though when I pasted that link. ;-)

I was more curious what LDC does if it stack allocates array literals assigned to static arrays in that program.  My guess is that the dynamic array will get the address of the stack allocated array literal, and it's values will be lost after calling fill();

If so, this is another bug that needs to be filled and fixed.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';