On 5/13/15 8:00 PM, Jakob Ovrum wrote:
On Wednesday, 13 May 2015 at 17:49:38 UTC, Steven Schveighoffer wrote:
OK, then consider that this:
void main()
{
string x;
x ~= hello;
x ~= world;
}
would require locking. That's unacceptable. Nobody would append with
strings if this all
On 2015-05-12 17:21:03 +, Steven Schveighoffer schvei...@yahoo.com said:
Of course, array appending is an odd duck here, as generally you are
not generally able to add data to an immutable piece of data.
A similar odd duck would be reference counting (again, mutable metadata
attached to
On Wednesday, 13 May 2015 at 17:49:38 UTC, Steven Schveighoffer
wrote:
OK, then consider that this:
void main()
{
string x;
x ~= hello;
x ~= world;
}
would require locking. That's unacceptable. Nobody would append
with strings if this all required locking for no reason. The
runtime
On 5/13/15 1:35 AM, Dicebot wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
x ~= 1; // should this lock;
y ~= 1; // should this lock?
As per my
On 5/13/15 3:02 AM, Jakob Ovrum wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
Do you mean:
immutable(int)[] x = new int[5];
const(int)[] y = x;
?
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
I think shared is broken in general, the only thing that's
great about it is *not* shared, which is defined by the absence
of shared :) That is something that's easy to wrap your head
around.
Yes, «shared» is either broken
On Wednesday, 13 May 2015 at 05:35:18 UTC, Dicebot wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
x ~= 1; // should this lock;
y ~= 1; // should this
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
Do you mean:
immutable(int)[] x = new int[5];
const(int)[] y = x;
?
Because you can't append to or reassign an
On Wednesday, 13 May 2015 at 06:23:40 UTC, Brad Anderson wrote:
On Wednesday, 13 May 2015 at 05:35:18 UTC, Dicebot wrote:
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[]
On 5/12/15 12:53 PM, Brad Anderson wrote:
On Tuesday, 12 May 2015 at 15:51:38 UTC, Steven Schveighoffer wrote:
The whole concept of immutable being implicitly shareable is kind of
broken. There are many reasons to have immutable unshared data, and it
poisons const to the point where you really
On Tuesday, 12 May 2015 at 15:51:38 UTC, Steven Schveighoffer
wrote:
The whole concept of immutable being implicitly shareable is
kind of broken. There are many reasons to have immutable
unshared data, and it poisons const to the point where you
really should consider any const variable to be
On 05/12/2015 05:52 PM, Steven Schveighoffer wrote:
On 5/10/15 8:58 AM, Timon Gehr wrote:
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
In C, C++, and D people have allocated memory for a long time in the
following manner:
...
Long story short, arrays should sit on a different heap than
On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer
wrote:
The one that always comes to my mind is array appending:
immutable int[] x = new int[5];
const int[] y = x;
x ~= 1; // should this lock;
y ~= 1; // should this lock?
As per my udnerstanding `shared` should _never_ result
On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
On 5/10/15 5:58 AM, Timon Gehr wrote:
Keep in mind that currently, entire regions of memory can
change from
mutable to immutable implicitly when returned from pure
functions.
Furthermore, as Michel points out, the ways
On 5/12/15 6:12 AM, Peter Alexander wrote:
Would it be better to name these after their interpretation, rather than
expected use cases? For example, the allocator doesn't care if something
is an array, it cares about resizing, and large block allocations.
Perhaps s/array/expectRealloc/ (as an
On 5/10/15 6:51 AM, Michel Fortin wrote:
On 2015-05-10 09:50:00 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is casting
On 5/10/15 8:58 AM, Timon Gehr wrote:
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
In C, C++, and D people have allocated memory for a long time in the
following manner:
...
Long story short, arrays should sit on a different heap than objects.
...
Unless this has been fixed in the
On Monday, 11 May 2015 at 09:55:36 UTC, Marc Schütz wrote:
In addition to an immutable/shared heap, it may also be
necessary to transfer data from one thread to another. The
shared heap is for data with shared ownership, while other data
with (unique) ownership can be sent to other threads.
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is
casting to shared.) This has a large performance cost that only
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is
casting to shared.) This has a large performance cost that only
On Monday, 11 May 2015 at 10:54:10 UTC, Jonathan M Davis wrote:
doing the allocation, but I don't see how we can get rid of the
possibility of an object being allocated on one thread and
deallocated on another without making major changes to shared -
and std.concurrency isn't going to work
On 5/10/15 5:58 AM, Timon Gehr wrote:
Keep in mind that currently, entire regions of memory can change from
mutable to immutable implicitly when returned from pure functions.
Furthermore, as Michel points out, the ways 'immutable' can be leveraged
is constrained by the fact that it implies
On 2015-05-11 17:45, Andrei Alexandrescu wrote:
For now, here's a snapshot of flags that the allocation primitives
should know about:
enum AllocOptions
{
/// Allocate an array, not an individual object
array,
/// Allocate a string of characters
string,
/// Plan to let the GC
On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
On 5/10/15 5:58 AM, Timon Gehr wrote:
Keep in mind that currently, entire regions of memory can
change from
mutable to immutable implicitly when returned from pure
functions.
Furthermore, as Michel points out, the ways
On 5/11/15 9:14 AM, Dicebot wrote:
On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
/// The caller is a pure function, so result may be immutable
fromPureFunction,
It should simply say that allocation pointer is unique, the fact that it
comes from pure functions is not
On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
/// The caller is a pure function, so result may be immutable
fromPureFunction,
It should simply say that allocation pointer is unique, the fact
that it comes from pure functions is not important on its own. It
should be
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
In C, C++, and D people have allocated memory for a long time in the
following manner:
...
Long story short, arrays should sit on a different heap than objects.
...
Unless this has been fixed in the interim, I believe DMD lowers new
S(args)
On 2015-05-10 09:50:00 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is casting to
shared.) This has a large performance
In C, C++, and D people have allocated memory for a long time in the
following manner:
1. Allocate as many bytes as needed (e.g. by using malloc);
2. Mess with the memory allocated.
(C++ took this one step further by defining class-specific allocators,
feature that D copied. That turned out
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
(file:///Users/aalexandre/code/d/dlang.org/web/phobos-prerelease/std_experimental_allocator_free_tree.html)
bad link
On Sunday, 10 May 2015 at 10:51:54 UTC, Michel Fortin wrote:
On 2015-05-10 09:50:00 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to
On 5/10/15 3:15 AM, anonymous wrote:
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
(file:///Users/aalexandre/code/d/dlang.org/web/phobos-prerelease/std_experimental_allocator_free_tree.html)
bad link
Pardon:
On 5/10/15 3:51 AM, Michel Fortin wrote:
Shared is implicit in the case of immutable. Think carefully: if you
implement this and it has any efficiency benefit for non-shared
allocations, const-allocated objects and arrays will become more
performant than immutable-allocated ones. People will
33 matches
Mail list logo
