Interesting read on the subject of ARC and GC:
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
It does seem that ARC would be a preferred strategy for D to
pursue (even if it's a first pass before resorting to GC sweeps).
Opps, just saw that this link was already posted here:
http://forum.dlang.org/thread/krhjq8$2r8l$1...@digitalmars.com
On 06/03/13 12:41, Paulo Pinto wrote:
> Am 03.06.2013 18:00, schrieb Manu:
>> Haha, wow. Indeed, isn't that well timed with respect to recent
>> discussions! ;)
>> Post-dconf, I gave it some serious thought and I'm kinda convincing
>> myself more and more each day that it's the way to go.
>>
>
> A
On 4 June 2013 03:41, Paulo Pinto wrote:
> Am 03.06.2013 18:00, schrieb Manu:
>
> Haha, wow. Indeed, isn't that well timed with respect to recent
>> discussions! ;)
>> Post-dconf, I gave it some serious thought and I'm kinda convincing
>> myself more and more each day that it's the way to go.
>>
On Monday, 3 June 2013 at 18:10:50 UTC, Kagamin wrote:
On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
Also a better GC in no way invalidates the need for other
memory management schemes because there will always be
situations where a GC is not an appropriate solution, at least
not until
On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
Also a better GC in no way invalidates the need for other
memory management schemes because there will always be
situations where a GC is not an appropriate solution, at least
not until someone invents the perfect one size fits all GC.
phob
On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
On Monday, 3 June 2013 at 16:01:29 UTC, H. S. Teoh wrote:
C++11 deprecated auto_ptr in favor of unique_ptr, but it's
basically the same concept, and it works very well in cases
where you prefer to manage your own memory. D should have the
s
Am 03.06.2013 18:00, schrieb Manu:
Haha, wow. Indeed, isn't that well timed with respect to recent
discussions! ;)
Post-dconf, I gave it some serious thought and I'm kinda convincing
myself more and more each day that it's the way to go.
As I mentioned I prefer GC based solutions, but then aga
On Monday, 3 June 2013 at 16:01:29 UTC, H. S. Teoh wrote:
C++11 deprecated auto_ptr in favor of unique_ptr, but it's
basically the same concept, and it works very well in cases where
you prefer to manage your own memory. D should have the same
thing in the std lib, it's not difficult to implem
On Mon, Jun 03, 2013 at 04:33:10PM +0200, Adam D. Ruppe wrote:
> On Monday, 3 June 2013 at 14:20:06 UTC, Dicebot wrote:
> >I don't see how struct with a disabled copy constructor is
> >relevant to owned pointers.
>
> My thought is then you can control access to the inner pointer
> better that way.
Haha, wow. Indeed, isn't that well timed with respect to recent
discussions! ;)
Post-dconf, I gave it some serious thought and I'm kinda convincing myself
more and more each day that it's the way to go.
On 3 June 2013 19:10, Paulo Pinto wrote:
> Even as GC fanboy, I have to admit that reference
On Monday, 3 June 2013 at 14:33:12 UTC, Adam D. Ruppe wrote:
My thought is then you can control access to the inner pointer
better that way. You couldn't even pass this struct to a
function without calling some kind of method, which could
return a different type to indicate that it is a lent po
On Monday, 3 June 2013 at 14:20:06 UTC, Dicebot wrote:
I don't see how struct with a disabled copy constructor is
relevant to owned pointers.
My thought is then you can control access to the inner pointer
better that way. You couldn't even pass this struct to a function
without calling some k
On Monday, 3 June 2013 at 14:04:23 UTC, Adam D. Ruppe wrote:
I think we could do the whole owned pointer concept in D too,
by making a struct with a disabled copy constructor. I don't
know much about Rust's specifics though so not sure if that's
an exact match.
I don't see how struct with a d
I think we could do the whole owned pointer concept in D too, by
making a struct with a disabled copy constructor. I don't know
much about Rust's specifics though so not sure if that's an exact
match.
But I'm already running with the idea that all slices are
"borrowed", so we could say the sa
Is it an official position or just a blog post / proposal from
one of developers?
Anyway, given the recent findings by Adam, D is not _that_ far
away here. Add configurable global allocators, finally implement
"scope", move GC to library and reduce runtime a bit - and result
may be pretty aw
Even as GC fanboy, I have to admit that reference counting is in
trend for system languages.
Rust developers are thinking to move GC support to the language
library while keeping reference counting as the main way to deal
with memory management.
http://pcwalton.github.io/blog/2013/06/02/remo
17 matches
Mail list logo
