On Monday, 23 September 2013 at 15:56:11 UTC, ponce wrote:
On Monday, 23 September 2013 at 15:45:25 UTC, Andrei
Alexandrescu wrote:
On 9/23/13 7:22 AM, ponce wrote:
One question: what circumstances require run-time alignment
values, and what values would those be? I'm currently under
the
If we're sharing potential allocators, I just partially
implemented a design inspired by a rather 'Bright' person.
(Please shoot me for that.)
http://pastebin.com/14jeVY4n
Based on:
http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941
On Fri, Sep 27, 2013 at 07:10:18PM +0200, Yota wrote:
If we're sharing potential allocators, I just partially implemented
a design inspired by a rather 'Bright' person. (Please shoot me for
that.)
*BANG*
T
--
They say that guns don't kill people, people kill people. Well I think
the gun
On Friday, 27 September 2013 at 17:32:28 UTC, Craig Dillabaugh
wrote:
On Friday, 27 September 2013 at 17:29:06 UTC, H. S. Teoh wrote:
On Fri, Sep 27, 2013 at 07:10:18PM +0200, Yota wrote:
If we're sharing potential allocators, I just partially
implemented
a design inspired by a rather 'Bright'
On Friday, 27 September 2013 at 17:29:06 UTC, H. S. Teoh wrote:
*BANG*
They say that guns don't kill people, people kill people.
Well I think
the gun helps. If you just stood there and yelled BANG, I don't
think
you'd kill too many people. -- Eddie Izzard, Dressed to Kil
Was that an
On Friday, 27 September 2013 at 17:29:06 UTC, H. S. Teoh wrote:
On Fri, Sep 27, 2013 at 07:10:18PM +0200, Yota wrote:
If we're sharing potential allocators, I just partially
implemented
a design inspired by a rather 'Bright' person. (Please shoot
me for
that.)
*BANG*
T
--
They say that
On Fri, Sep 27, 2013 at 07:33:40PM +0200, Dicebot wrote:
On Friday, 27 September 2013 at 17:32:28 UTC, Craig Dillabaugh
wrote:
On Friday, 27 September 2013 at 17:29:06 UTC, H. S. Teoh wrote:
On Fri, Sep 27, 2013 at 07:10:18PM +0200, Yota wrote:
If we're sharing potential allocators, I just
On 2013-09-25 18:13, kraybit wrote:
I believe Manu's example was about X having template parameters as well.
As in
auto v = new Vec3!float(0,0,0);
Either way, what would it be then? a) or b)?
auto v = new!(Vec3!float)(0,0,0); // a)
auto v = new!(Vec3!float(0,0,0)); // b)
?
On 2013-09-25 20:27, Johannes Pfau wrote:
Having the compiler rewrite
new(MallocAllocator) MyClass(a,b,c)
to
void[] __buf = MallocAllocator.it.allocate(MyClass.instancesize);
__construct!MyClass(__buf, a, b, c); //Has to handle context ptr
seems like a good solution. It probably has to
On Tuesday, 24 September 2013 at 22:39:27 UTC, Andrei
Alexandrescu wrote:
On 9/24/13 3:11 PM, Namespace wrote:
I would rather want new to be overloadable and have 2 sets of
parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded version of new
and arg1
and arg2
Am 25.09.2013 00:39, schrieb Andrei Alexandrescu:
On 9/24/13 3:11 PM, Namespace wrote:
I would rather want new to be overloadable and have 2 sets of parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded version of new and arg1
and arg2 will be passed to the
On 9/23/13 20:52 , Jacob Carlborg wrote:
On 2013-09-23 17:47, Manu wrote:
X x = new!(X!arg(args...)); // ewoo, paren spam...
Why not:
X x = new!X(args);
I believe Manu's example was about X having template parameters as well.
As in
auto v = new Vec3!float(0,0,0);
Either way,
I mean, if one could get away with
auto v = new! Vec3!float(0,0,0);
it'd be pretty nice?
Or perhaps patently confusing..
*more coffee*
On 9/25/13 9:13 AM, kraybit wrote:
On 9/23/13 20:52 , Jacob Carlborg wrote:
On 2013-09-23 17:47, Manu wrote:
X x = new!(X!arg(args...)); // ewoo, paren spam...
Why not:
X x = new!X(args);
I believe Manu's example was about X having template parameters as well.
As in
auto v = new
Am Wed, 25 Sep 2013 17:22:28 +0200
schrieb Benjamin Thaut c...@benjamin-thaut.de:
Am 25.09.2013 00:39, schrieb Andrei Alexandrescu:
We're banning that syntax of new.
Andrei
I always love it when people just plain ignore all the arguments I
made ...
I think there's a
On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu
wrote:
struct NullAllocator
{
enum alignment = real.alignof;
enum size_t available = 0;
ubyte[] allocate(size_t s) shared { return null; }
bool expand(ref ubyte[] b, size_t minDelta, size_t
maxDelta) shared
{
On Wednesday, 25 September 2013 at 01:22:46 UTC, deadalnix wrote:
On Tuesday, 24 September 2013 at 15:57:00 UTC, Andrei
Alexandrescu wrote:
Also, I hope we'll be able to allow allocators to define
Pointer(T), Ref(T) etc. that supplant replacements for the
built-in notions of pointer, reference
On 9/25/13 12:03 PM, Peter Alexander wrote:
On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu wrote:
struct NullAllocator
{
enum alignment = real.alignof;
enum size_t available = 0;
ubyte[] allocate(size_t s) shared { return null; }
bool expand(ref ubyte[] b,
Am 25.09.2013 20:27, schrieb Johannes Pfau:
Am Wed, 25 Sep 2013 17:22:28 +0200
schrieb Benjamin Thaut c...@benjamin-thaut.de:
Am 25.09.2013 00:39, schrieb Andrei Alexandrescu:
We're banning that syntax of new.
Andrei
I always love it when people just plain ignore all the arguments I
made
On 24 September 2013 15:31, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/23/13 9:56 PM, Manu wrote:
You can't go wasting GPU memory by overallocating every block.
Only the larger chunk may need to be overallocated if all allocations are
then rounded up.
I don't follow.
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I talked Walter's ear off a while ago at an ACCU conference about the
notion that reference counting could be a switch passed to the compiler.
Recently he's authored a DIP about the compiler inserting refcounting
primitives in the generated code.
On 2013-09-24 02:03, H. S. Teoh wrote:
I thought Walter's DIP already addresses the issue of replacing the
default allocator?
http://wiki.dlang.org/DIP46
I get the feeling that we don't have a good handle on the fundamental
issues, though. Having a stack for managing the default
On 2013-09-23 22:32, Timon Gehr wrote:
Some general remarks:
One issue you will probably run into and maybe want to fix in some way
during the typed allocator design is that private constructors cannot be
called from templates parameterized on types.
E.g.:
module a;
auto New(T,Args...)(Args
23-Sep-2013 03:49, Andrei Alexandrescu пишет:
Hello,
I am making good progress on the design of std.allocator, and I am
optimistic about the way it turns out. D's introspection capabilities
really shine through, and in places the design does feel really
archetypal - e.g. this is the essence of
On Mon, 2013-09-23 at 10:53 -0700, Andrei Alexandrescu wrote:
void deallocate(void[] buffer);
This is because the size of D objects is naturally known: classes
have
it in the classinfo, slices store it, and the few cases of using bald
pointers for allocation are irrelevant and
One thing I'm not sure is addressed by this design is memory
locality. I know of libnuma http://linux.die.net/man/3/numa which
allows me to express what NUMA domain my memory should be
allocated from at run-time for each allocation.
In the case that I want to allocate memory in a specific
On Tuesday, 24 September 2013 at 11:38:29 UTC, Dan Schatzberg
wrote:
One thing I'm not sure is addressed by this design is memory
locality. I know of libnuma http://linux.die.net/man/3/numa
which allows me to express what NUMA domain my memory should be
allocated from at run-time for each
On Tuesday, 24 September 2013 at 13:21:48 UTC, deadalnix wrote:
On Tuesday, 24 September 2013 at 11:38:29 UTC, Dan Schatzberg
wrote:
One thing I'm not sure is addressed by this design is memory
locality. I know of libnuma http://linux.die.net/man/3/numa
which allows me to express what NUMA
On 9/23/13 11:06 PM, Manu wrote:
On 24 September 2013 15:31, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
On 9/23/13 9:56 PM, Manu wrote:
You can't go wasting GPU memory by overallocating every block.
Only the larger chunk may
On 9/23/13 11:32 PM, Jacob Carlborg wrote:
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I talked Walter's ear off a while ago at an ACCU conference about the
notion that reference counting could be a switch passed to the compiler.
Recently he's authored a DIP about the compiler inserting
On 9/24/13 1:46 AM, Dmitry Olshansky wrote:
23-Sep-2013 03:49, Andrei Alexandrescu пишет:
Looks good (s/ubyte[]/void[] per current discussion).
Changed.
Do you imagine Typed allocators as something more then adapters that
simplify a common pattern of allocate + emplace / destroy +
On 9/24/13 2:49 AM, Robert wrote:
On Mon, 2013-09-23 at 10:53 -0700, Andrei Alexandrescu wrote:
void deallocate(void[] buffer);
This is because the size of D objects is naturally known: classes
have
it in the classinfo, slices store it, and the few cases of using bald
pointers for allocation
On 9/24/13 4:38 AM, Dan Schatzberg wrote:
One thing I'm not sure is addressed by this design is memory locality. I
know of libnuma http://linux.die.net/man/3/numa which allows me to
express what NUMA domain my memory should be allocated from at run-time
for each allocation.
In the case that I
On 9/24/13 9:12 AM, Paulo Pinto wrote:
Am 24.09.2013 17:29, schrieb Andrei Alexandrescu:
On 9/23/13 11:32 PM, Jacob Carlborg wrote:
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I think this is debatable. For one, languages such as Java and C++
still
have built-in new but quite
Am 24.09.2013 17:29, schrieb Andrei Alexandrescu:
On 9/23/13 11:32 PM, Jacob Carlborg wrote:
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I think this is debatable. For one, languages such as Java and C++ still
have built-in new but quite ubiquitously unrecommend their usage in
user code.
On Tuesday, 24 September 2013 at 08:46:36 UTC, Dmitry Olshansky
wrote:
23-Sep-2013 03:49, Andrei Alexandrescu пишет:
Hello,
I am making good progress on the design of std.allocator, and
I am
optimistic about the way it turns out. D's introspection
capabilities
really shine through, and in
On 9/24/13 9:39 AM, Brad Anderson wrote:
Somewhat related: http://probablydance.com/2013/05/13/4gb-per-vector/
Great insight, long scroll. Please trim quoting appropriately.
Andrei
Am 24.09.2013 18:14, schrieb Andrei Alexandrescu:
On 9/24/13 9:12 AM, Paulo Pinto wrote:
Am 24.09.2013 17:29, schrieb Andrei Alexandrescu:
On 9/23/13 11:32 PM, Jacob Carlborg wrote:
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I think this is debatable. For one, languages such as Java
On Tuesday, 24 September 2013 at 15:25:11 UTC, Andrei
Alexandrescu wrote:
What are they paying exactly? An extra arg to allocate that
can probably
be defaulted?
void[] allocate(size_t bytes, size_t align = this.alignment)
shared;
For allocating relatively small objects (say up to 32K),
On 9/24/13 9:58 AM, Peter Alexander wrote:
On Tuesday, 24 September 2013 at 15:25:11 UTC, Andrei Alexandrescu wrote:
What are they paying exactly? An extra arg to allocate that can probably
be defaulted?
void[] allocate(size_t bytes, size_t align = this.alignment) shared;
For allocating
On Tuesday, 24 September 2013 at 16:58:27 UTC, Peter Alexander
wrote:
The cost of a few cycles really doesn't matter for memory
allocation... If you are really allocating memory so frequently
that those few extra cycles matter then you are probably going
to be memory bound anyway.
It is true
On 9/24/13 10:05 AM, Dicebot wrote:
On Tuesday, 24 September 2013 at 16:58:27 UTC, Peter Alexander wrote:
The cost of a few cycles really doesn't matter for memory
allocation... If you are really allocating memory so frequently that
those few extra cycles matter then you are probably going to
On Tuesday, 24 September 2013 at 16:06:39 UTC, Andrei
Alexandrescu wrote:
On 9/24/13 4:38 AM, Dan Schatzberg wrote:
One thing I'm not sure is addressed by this design is memory
locality. I
know of libnuma http://linux.die.net/man/3/numa which allows
me to
express what NUMA domain my memory
On Tuesday, 24 September 2013 at 17:02:18 UTC, Andrei
Alexandrescu wrote:
On 9/24/13 9:58 AM, Peter Alexander wrote:
On Tuesday, 24 September 2013 at 15:25:11 UTC, Andrei
Alexandrescu wrote:
What are they paying exactly? An extra arg to allocate that
can probably
be defaulted?
void[]
On Tuesday, 24 September 2013 at 17:38:34 UTC, Dan Schatzberg
wrote:
What is your objective though? Aren't you trying to define a
hierarchy of allocators where more specific allocators can be
composed from general ones? In which case what is the concern
with including locality at the base
On 24.09.2013 10:46, Dmitry Olshansky wrote:
* expand(b, minDelta, maxDelta) grows b's length by at least minDelta
(and on a best-effort basis by at least maxDelta) and returns true, or
does nothing and returns false. In most allocators this should be @safe.
(One key insight is that expand()
Hi,
I mostly just lurk around here, but occasionally I just can't
resist putting in my two cents. I really want to see D replace
C++ for AAA games (my industry) and allocators are really
critical to that. I think there's an elephant here that most of
the posts have been dancing around.
24-Sep-2013 22:28, Rainer Schuetze пишет:
On 24.09.2013 10:46, Dmitry Olshansky wrote:
* expand(b, minDelta, maxDelta) grows b's length by at least minDelta
(and on a best-effort basis by at least maxDelta) and returns true, or
does nothing and returns false. In most allocators this should
On 9/24/13 11:02 AM, Peter Alexander wrote:
On Tuesday, 24 September 2013 at 17:02:18 UTC, Andrei Alexandrescu wrote:
On 9/24/13 9:58 AM, Peter Alexander wrote:
On Tuesday, 24 September 2013 at 15:25:11 UTC, Andrei Alexandrescu
wrote:
What are they paying exactly? An extra arg to allocate
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
On 24.09.2013 10:46, Dmitry Olshansky wrote:
* expand(b, minDelta, maxDelta) grows b's length by at least minDelta
(and on a best-effort basis by at least maxDelta) and returns true, or
does nothing and returns false. In most allocators this
24-Sep-2013 23:36, Andrei Alexandrescu пишет:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
[snip]
which causes confusion - people will pass small sizes to expand()
expecting it to contract, something that expand() can't support as a
matter of principle (safety!!!).
Showstopper. It has to
24-Sep-2013 20:48, Andrei Alexandrescu пишет:
On 9/24/13 9:39 AM, Brad Anderson wrote:
Somewhat related: http://probablydance.com/2013/05/13/4gb-per-vector/
Great insight, long scroll. Please trim quoting appropriately.
Andrei
In fact one may have both deque (just start in the middle) and
On 9/24/13 12:47 PM, Dmitry Olshansky wrote:
24-Sep-2013 23:36, Andrei Alexandrescu пишет:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
[snip]
which causes confusion - people will pass small sizes to expand()
expecting it to contract, something that expand() can't support as a
matter of
On 9/24/13 12:49 PM, Andrei Alexandrescu wrote:
On 9/24/13 12:47 PM, Dmitry Olshansky wrote:
24-Sep-2013 23:36, Andrei Alexandrescu пишет:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
[snip]
which causes confusion - people will pass small sizes to expand()
expecting it to contract,
24-Sep-2013 19:56, Andrei Alexandrescu пишет:
On 9/24/13 1:46 AM, Dmitry Olshansky wrote:
23-Sep-2013 03:49, Andrei Alexandrescu пишет:
Do you imagine Typed allocators as something more then adapters that
simplify a common pattern of allocate + emplace / destroy + deallocate?
On 9/24/13 11:20 AM, Dan Schatzberg wrote:
On Tuesday, 24 September 2013 at 17:38:34 UTC, Dan Schatzberg wrote:
What is your objective though? Aren't you trying to define a hierarchy
of allocators where more specific allocators can be composed from
general ones? In which case what is the
On 9/24/13 1:02 PM, Dmitry Olshansky wrote:
24-Sep-2013 19:56, Andrei Alexandrescu пишет:
It could, but as I mentioned to Manu - at this level any cost is
significant. Even changing from a compile-time constant to a global
static dynamically-initialized constant has a cost. Making alignment an
On 24.09.2013 21:36, Andrei Alexandrescu wrote:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
expand is nice, but I don't like minDelta and maxDelta as arguments. On
a shared allocator this can lead to undesired side-effects, i.e. when
this function is called concurrently on the same block by
On 9/24/13 2:02 PM, Rainer Schuetze wrote:
On 24.09.2013 21:36, Andrei Alexandrescu wrote:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
expand is nice, but I don't like minDelta and maxDelta as arguments. On
a shared allocator this can lead to undesired side-effects, i.e. when
this function
On 24.09.2013 23:05, Andrei Alexandrescu wrote:
Taking the current array implementation as an example, the deltas are
computed before the actual GC lock happens inside gc_extend which means
that the second of two concurrent requests leads to overallocation.
(I'm confused - which array
On Tue, 24 Sep 2013 08:29:39 -0700
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 9/23/13 11:32 PM, Jacob Carlborg wrote:
On 2013-09-23 19:53, Andrei Alexandrescu wrote:
I think this is debatable. For one, languages such as Java and C++
still have built-in new but quite
I would rather want new to be overloadable and have 2 sets of
parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded version of new and
arg1 and arg2 will be passed to the constructor.
+1
Also, how does it work with your deallocate interface? Suppose
I request an 0x100 aligned block of 0x100 bytes. Your alignment
allocator requests 0x200 from the GC, which maybe returns
[0x0040-0x0240] and then returns an aligned buffer from
that [0x0100-0x0200]. Later, I try to
25-Sep-2013 01:05, Andrei Alexandrescu пишет:
On 9/24/13 2:02 PM, Rainer Schuetze wrote:
[snip]
Why would you expect a function expand to reduce the memory size?
Ask Dmitry :o). Far as I can tell he assumed so.
I had read it as reallocate in place. Yeah, my semantic reading must
suck
On 9/24/13 3:11 PM, Namespace wrote:
I would rather want new to be overloadable and have 2 sets of parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded version of new and arg1
and arg2 will be passed to the constructor.
+1
We're banning that syntax of new.
25-Sep-2013 00:39, Andrei Alexandrescu пишет:
On 9/24/13 1:02 PM, Dmitry Olshansky wrote:
24-Sep-2013 19:56, Andrei Alexandrescu пишет:
It could, but as I mentioned to Manu - at this level any cost is
significant. Even changing from a compile-time constant to a global
static
On Tuesday, 24 September 2013 at 15:57:00 UTC, Andrei
Alexandrescu wrote:
Also, I hope we'll be able to allow allocators to define
Pointer(T), Ref(T) etc. that supplant replacements for the
built-in notions of pointer, reference etc. Then, user code
that uses these notions instead of the
Andrei Alexandrescu:
Also, I hope we'll be able to allow allocators to define
Pointer(T), Ref(T) etc. that supplant replacements for the
built-in notions of pointer, reference etc. Then, user code
that uses these notions instead of the built-in ones will be
guaranteed some nice properties
On Tuesday, 24 September 2013 at 19:27:13 UTC, Andrei
Alexandrescu wrote:
Second, there's no need for a defaulted argument; the aligned
allocation can be an optional overload of the one-argument
function. I'm looking into ways to compose with that overload.
This or something like
On Tuesday, 24 September 2013 at 22:39:27 UTC, Andrei
Alexandrescu wrote:
On 9/24/13 3:11 PM, Namespace wrote:
I would rather want new to be overloadable and have 2 sets of
parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded version of new
and arg1
and arg2
On Tuesday, 24 September 2013 at 18:53:56 UTC, Bigsandwich wrote:
Hi,
I mostly just lurk around here, but occasionally I just can't
resist putting in my two cents. I really want to see D replace
C++ for AAA games (my industry) and allocators are really
critical to that. I think there's an
On 9/24/13 6:42 PM, deadalnix wrote:
On Tuesday, 24 September 2013 at 22:39:27 UTC, Andrei Alexandrescu wrote:
On 9/24/13 3:11 PM, Namespace wrote:
I would rather want new to be overloadable and have 2 sets of
parameters
new (allocator)(arg1, arg2)
Where allocator would go to the overloaded
On Monday, 23 September 2013 at 04:19:34 UTC, Manu wrote:
You've just described C++ verbatim.
And you've previously agreed that C++'s approach totally
failed. Can you
explain how this is different from C++, and how it solves the
issues that
defeated that design?
One possibility I'm keeping
On 2013-09-23 01:49, Andrei Alexandrescu wrote:
I am making good progress on the design of std.allocator, and I am
optimistic about the way it turns out. D's introspection capabilities
really shine through, and in places the design does feel really
archetypal - e.g. this is the essence of a
On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu
wrote:
...
In general I like it though I do agree with concerns mentioned
that without speculation about high-level API and usage examples
it is rather hard to evaluate its practical applicability. For
example, you have
On Monday, 23 September 2013 at 07:31:46 UTC, Jacob Carlborg
wrote:
On 2013-09-23 01:49, Andrei Alexandrescu wrote:
I am making good progress on the design of std.allocator, and
I am
optimistic about the way it turns out. D's introspection
capabilities
really shine through, and in places the
On 23 September 2013 15:37, Walter Bright newshou...@digitalmars.comwrote:
On 9/22/2013 9:19 PM, Manu wrote:
Following this train of thought, I can imagine a really nice end goal
would be
that the existing GC is effectively plugged in as a library, and people
can
easily substitute it for
On 9/23/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
Why ubyte[] and not void[]?
Probably to make the GC avoid scanning into the array.
On 2013-09-23 11:31, qznc wrote:
5. Class local - The allocator is used for specific types (e.g. ASTNode
in a compiler)
6. Class-hierarchy - The allocator is used for a specific type hierarchy
(e.g. ASTNode might have sub classes Statement,BinOp,etc)
7. Container local - The C++ way which
On 9/22/13 9:03 PM, Manu wrote:
On 23 September 2013 12:28, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
My design makes it very easy to experiment by allowing one to define
complex allocators out of a few simple building blocks. It is not
On 9/22/13 9:19 PM, Manu wrote:
On 23 September 2013 13:01, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
Containers and other objects that want to allow customization of
their allocation would be parameterized during compilation with an
On 24 September 2013 00:04, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/22/13 10:20 PM, Benjamin Thaut wrote:
Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
Hello,
2. Untyped allocator - traffics exclusively in ubyte[].
Why ubyte[] and not void[]?
It's the
On 9/22/13 10:37 PM, Walter Bright wrote:
On 9/22/2013 9:19 PM, Manu wrote:
Following this train of thought, I can imagine a really nice end goal
would be
that the existing GC is effectively plugged in as a library, and
people can
easily substitute it for their own GC if they want/need to.
It
On 23 September 2013 23:38, Jacob Carlborg d...@me.com wrote:
On 2013-09-23 11:31, qznc wrote:
5. Class local - The allocator is used for specific types (e.g. ASTNode
in a compiler)
6. Class-hierarchy - The allocator is used for a specific type hierarchy
(e.g. ASTNode might have sub
On 9/22/13 10:20 PM, Benjamin Thaut wrote:
Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
Hello,
2. Untyped allocator - traffics exclusively in ubyte[].
Why ubyte[] and not void[]?
It's the logical choice at this level.
ubyte[] == these are octets
Andrei
On 9/23/13 1:03 AM, Dicebot wrote:
On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu wrote:
...
In general I like it though I do agree with concerns mentioned that
without speculation about high-level API and usage examples it is rather
hard to evaluate its practical
On 9/23/13 4:39 AM, Andrej Mitrovic wrote:
On 9/23/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
Why ubyte[] and not void[]?
Probably to make the GC avoid scanning into the array.
No, that's determined at runtime by how the blocks are allocated.
Andrei
On 9/23/13 12:31 AM, Jacob Carlborg wrote:
On 2013-09-23 01:49, Andrei Alexandrescu wrote:
I am making good progress on the design of std.allocator, and I am
optimistic about the way it turns out. D's introspection capabilities
really shine through, and in places the design does feel really
On 2013-09-23, 15:58, Andrei Alexandrescu wrote:
I had imagined going into this that, like the range interface which the
_language_ understands and interacts with, the allocator interface would
be the same, ie, the language would understand this API and integrate it
with 'new', and the GC...
On 9/23/13 7:07 AM, Manu wrote:
On 24 September 2013 00:04, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
On 9/22/13 10:20 PM, Benjamin Thaut wrote:
Am 23.09.2013 01:49, schrieb Andrei Alexandrescu:
Hello,
Great news! It looks like a big improvement on akward C++
allocators.
(For what it's worth I have a working implementation of aligned
malloc/free/realloc here
https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which
can be the basis for an allocator layered upon another)
On 9/23/13 7:22 AM, ponce wrote:
Great news! It looks like a big improvement on akward C++ allocators.
(For what it's worth I have a working implementation of aligned
malloc/free/realloc here
https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which can be
the basis for an allocator
On 24 September 2013 00:49, Andrei Alexandrescu
seewebsiteforem...@erdan.org wrote:
Simen Kjaeraas simen.kja...@gmail.com wrote:
On 2013-09-23, 15:58, Andrei Alexandrescu wrote:
I had imagined going into this that, like the range interface which the
_language_ understands and interacts
On 9/23/13 8:02 AM, Adam D. Ruppe wrote:
We should really deprecate the new keyword. It'd break like all code
ever, but with D's templates, there's no need for it, and when it is
there, it is going to spark problems about replacing global allocators
or the library allocators being second class
On 24 September 2013 00:05, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/22/13 10:37 PM, Walter Bright wrote:
On 9/22/2013 9:19 PM, Manu wrote:
Following this train of thought, I can imagine a really nice end goal
would be
that the existing GC is effectively plugged in as
We should really deprecate the new keyword. It'd break like all
code ever, but with D's templates, there's no need for it, and
when it is there, it is going to spark problems about replacing
global allocators or the library allocators being second class
citizens.
Maybe we could minimize the
Simen Kjaeraas simen.kja...@gmail.com wrote:
On 2013-09-23, 15:58, Andrei Alexandrescu wrote:
I had imagined going into this that, like the range interface which the
_language_ understands and interacts with, the allocator interface would
be the same, ie, the language would understand this
On 9/23/13 7:50 AM, Manu wrote:
delete is important if your class is being allocated by a pool or
something...
It's important as an API function, but not as a language primitive.
new should also have been a function.
But you said before, people won't use 'new' if they are using an
On 9/23/13 7:22 AM, ponce wrote:
Great news! It looks like a big improvement on akward C++ allocators.
(For what it's worth I have a working implementation of aligned
malloc/free/realloc here
https://github.com/p0nce/gfm/blob/master/gfm/core/memory.d, which can be
the basis for an allocator
On 23 September 2013 23:58, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/22/13 9:03 PM, Manu wrote:
On 23 September 2013 12:28, Andrei Alexandrescu
seewebsiteforem...@erdani.org
mailto:SeeWebsiteForEmail@**erdani.orgseewebsiteforem...@erdani.org
wrote:
My design
1 - 100 of 157 matches
Mail list logo
