Given all of this talk about memory management, it would seem
that it's time for people to start putting forward some ideas for
improved memory management designs. I've got an idea or two of my
own, but I'd like to discuss my ideas before I draft a DIP so I
can try to get everything fleshed out
Do you know this pull?
https://github.com/D-Programming-Language/dmd/pull/1903
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
...
I am pretty sure stuff like @nogc (or probably @noheap. or both)
will have no problems in being accepted into the mainstream once
properly implemented. It is mostly a matter of volunteer wanting
to get dirty with the compiler.
On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
Given all of this talk about memory management, it would seem
that it's time for people to start putting forward some ideas
for improved memory management designs. I've got an idea or two
of my own, but I'd like to discuss my ideas before I
On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
1. "scope": refers to stack-allocated memory (which seems to be
the original design behind "scope"). "scope" references may not
be stashed anywhere where they might become invalid. Since this
is the "safest" type of reference, any object ma
On 10 July 2013 17:53, Dicebot wrote:
> On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
>
>> ...
>>
>
> I am pretty sure stuff like @nogc (or probably @noheap. or both) will have
> no problems in being accepted into the mainstream once properly
> implemented. It is mostly a matter of volunt
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
I'd push for an ARC implementation. I've become convinced
that's what I
actually want, and that GC will never completely satisfy my
requirements.
I think those issues are actually orthogonal. I'd love to have
verified @noheap attribute e
On Wednesday, 10 July 2013 at 08:09:46 UTC, Dicebot wrote:
Yes, this is a common issue not unique to @nogc. I am
personally much in favor of having restrictive attributes
enabled by default and then adding "mutable" "@system" and
"@allowheap" where those are actually needed. But unfortunately
On Wednesday, 10 July 2013 at 08:16:55 UTC, Mr. Anonymous wrote:
I thought about allowing attributes to be applied to a whole
module, such as:
@safe @nogc module foo_bar;
Then, "@system", "@allowheap" and friends could be used where
needed.
You can do it, but it is not always possible to "di
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On 10 July 2013 17:53, Dicebot wrote:
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
...
I am pretty sure stuff like @nogc (or probably @noheap. or
both) will have
no problems in being accepted into the mainstream once prope
On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On 10 July 2013 17:53, Dicebot wrote:
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
...
I am pretty sure stuff like @nogc (or probably @noheap. or
both) will ha
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
...
@nogc itself does not help here as this code will still be
affected by stop-the-world. Those issues are related, but not
directly.
It will help to avoid memory leaks when you switch the GC off
though.
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On 10 July 2013 17:53, Dicebot wrote:
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
...
I am pretty sure s
On 2013-07-10 08:00:42 +, Manu said:
I'd push for an ARC implementation. I've become convinced that's what I
actually want, and that GC will never completely satisfy my requirements.
There's two ways to implement ARC. You can implement it instead of the
GC, but things with cycles in them
On Wednesday, 10 July 2013 at 10:49:04 UTC, Dicebot wrote:
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
...
@nogc itself does not help here as this code will still be
affected by stop-the-world. Those issues are related, but not
directly.
It will help to avoid memory leaks when yo
On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On 10 July 2013 17:53, Dicebot wrote:
On Wednesday, 10
On Wednesday, 10 July 2013 at 11:38:35 UTC, JS wrote:
On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
most functions may actually be @nogc
Most functions can't be @nogc because they throw exceptions.
Kagamin:
Most functions can't be @nogc because they throw exceptions.
Probably about half of my functions/metods are tagged with
"nothrow". And as ".dup" becomes nothrow and few more functions
become nothrow (iota, etc), that percentage will increase. I have
also proposed to add to Phobos s
On Wednesday, 10 July 2013 at 13:00:53 UTC, Kagamin wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
most functions may actually be @nogc
Most functions can't be @nogc because they throw exceptions.
I think I mentioned before, elsewhere, that @nogc could allow
exceptions. No o
On Wednesday, 10 July 2013 at 13:57:50 UTC, John Colvin wrote:
How much of the exception model would have to change in order
to free them from the GC? I don't see high performance as a
concern for exceptions so even an inefficient situation would
be fine.
Well, you can just throw malloc'ed ex
On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
Given all of this talk about memory management, it would seem
that it's time for people to start putting forward some ideas
for improved memory management designs. I've got an idea or two
of my own, but I'd like to discuss my ideas before I
sclytrack:
Why not just go manual memory. Just store everything
in a tree-like structure.
SuperOwner
--Child1
--Child2
SubChild1
SubChild2
--Container1
--Container2
--TStringList
Freeing a Child2 disposes of everything below.
Something like this?
http://swapped.cc/?_escap
Am 10.07.2013 15:57, schrieb John Colvin:
On Wednesday, 10 July 2013 at 13:00:53 UTC, Kagamin wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
most functions may actually be @nogc
Most functions can't be @nogc because they throw exceptions.
I think I mentioned before, elsewher
Am Wed, 10 Jul 2013 18:12:42 +0200
schrieb Paulo Pinto :
> Who is going to write two versions of the library then?
>
> Throwing exceptions with @nogc pointers floating around would just
> lead to the same headache as in C++.
This will really be an issue if/once we support systems which just
can'
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
One can already choose their own memory model in their own
code. The issue is with the core library and pre-existing code
that forces you to use the GC model.
It's possible to use your own memory model, but that doesn't mean
it's necessa
26 matches
Mail list logo
