Re: scoped allocations

2013-11-28 Thread Denis Shelomovskij

27.11.2013 3:33, Namespace пишет:

First of all: I apologize for my bad english.

In the last few weeks I searched for a way to allocate nicely temporary
buffer of unknown lengths.


You can use `unstd.memory.allocation.tempAlloc` [1]. Also there is 
`unstd.c.string.tempCString` [2] for common case of temporary C strings.


[1] 
http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc

[2] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString

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


Re: scoped allocations

2013-11-28 Thread Namespace
On Thursday, 28 November 2013 at 17:12:01 UTC, Denis Shelomovskij 
wrote:

27.11.2013 3:33, Namespace пишет:

First of all: I apologize for my bad english.

In the last few weeks I searched for a way to allocate nicely 
temporary

buffer of unknown lengths.


You can use `unstd.memory.allocation.tempAlloc` [1]. Also there 
is `unstd.c.string.tempCString` [2] for common case of 
temporary C strings.


[1] 
http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc
[2] 
http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString


Currently I use something like:

import std.stdio;
import core.memory : GC;

struct scoped(A : T[], T) {
T[] arr;

this(T[] arr) {
this.arr = arr;
		writefln(Allocate %d %s's (ptr = %x), arr.length, T.stringof, 
arr.ptr);

}

alias arr this;

@disable
this(this);

~this() {
		writefln(Deallocate %d %s's (ptr = %x), this.arr.length, 
T.stringof, this.arr.ptr);

version(none) {
GC.free(this.arr.ptr);
} else {
delete this.arr;
}

GC.minimize();
this.arr = null;
}
}

void main() {
scoped!(int[]) bytes = new int[100_000];
}


It's the nearest to scope int[] bytes = new int[100_000]; I could 
find.


Re: scoped allocations

2013-11-27 Thread Andrea Fontana

On Tuesday, 26 November 2013 at 23:33:59 UTC, Namespace wrote:


Temp!int arr = Temp!int(512); /// arr is destroyed at the end 
of the scope



But that does not look very nice (especially because Temp!int 
does not indicate that it holds an array).


If you call it something other than Temp maybe it sounds better.

auto arr = ScopedArray!int(512);

Makes sense for me.


Re: scoped allocations

2013-11-27 Thread Sönke Ludwig
Am 27.11.2013 09:54, schrieb Andrea Fontana:
 On Tuesday, 26 November 2013 at 23:33:59 UTC, Namespace wrote:

 Temp!int arr = Temp!int(512); /// arr is destroyed at the end of the
 scope
 

 But that does not look very nice (especially because Temp!int does not
 indicate that it holds an array).
 
 If you call it something other than Temp maybe it sounds better.
 
 auto arr = ScopedArray!int(512);
 
 Makes sense for me.

+ (I think that) std.container.Array does exactly the desired thing
(haven't used it so far).


Re: scoped allocations

2013-11-27 Thread Namespace
On Wednesday, 27 November 2013 at 08:55:01 UTC, Andrea Fontana 
wrote:

On Tuesday, 26 November 2013 at 23:33:59 UTC, Namespace wrote:


Temp!int arr = Temp!int(512); /// arr is destroyed at the end 
of the scope



But that does not look very nice (especially because Temp!int 
does not indicate that it holds an array).


If you call it something other than Temp maybe it sounds 
better.


auto arr = ScopedArray!int(512);

Makes sense for me.


It was just an example, but you're right. But even auto arr = 
ScopedArray!int(512); doesn't look very nice. Some syntax sugar 
like e.g. scope int[] arr = new int[512]; would be much nicer + 
more intuitive.


And with some of the other examples, like the DIP 46 variant, D 
could keep his promise to work even without a GC.
Currently you can disable it, but then you have very little 
benefit of the most basic things, such as strings, arrays, etc. 
With an exchangeable GC this would be different.


Re: scoped allocations

2013-11-26 Thread Namespace

On Tuesday, 26 November 2013 at 23:33:59 UTC, Namespace wrote:

First of all: I apologize for my bad english.

In the last few weeks I searched for a way to allocate nicely 
temporary buffer of unknown lengths.


Should be [...] of unknown lengths at compile time.