And 2k18 passes and there will be no precise gc this year it
seems.
Great D language. Better to think to move from it away.
On Monday, 27 November 2017 at 18:32:39 UTC, Ola Fosheim Grøstad
wrote:
You get this:
shared_ptr -> control_block -> object
Actually, seems like the common implementation uses 16 bytes, so
that it has a direct pointer as well. So twice the size of
unique_ptr.
On Monday, 27 November 2017 at 20:13:35 UTC, Dmitry Olshansky
wrote:
I’ve seen a tech giant that works on uber high-performance
things making heavy use of STL, and being fond of C++14
“high-level” features.
Look, I am not against "high level" features, but shared_ptr is
nothing like the
On Monday, 27 November 2017 at 18:29:56 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky
wrote:
Really, shared_ptr is the most contagious primitive of modern
C++.
Not really. Unique_ptr is, though.
To quote MS STL guy “I’m surprised we had no
On Monday, 27 November 2017 at 18:00:59 UTC, Jonathan M Davis
wrote:
I don't understand this. I would expect most modern C++
programs to be using shared_ptr as the default for most
pointers and thus use it heavily.
You get this:
shared_ptr -> control_block -> object
Instead of this:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky
wrote:
Really, shared_ptr is the most contagious primitive of modern
C++.
Not really. Unique_ptr is, though.
To quote MS STL guy “I’m surprised we had no non-inteusive
ref-counted ptr in std lib for so long”.
Going Native videos
On Monday, November 27, 2017 15:56:09 Ola Fosheim Grostad via Digitalmars-d
wrote:
> On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
>
> wrote:
> > Then watch Herb’s Sutter recent talk “Leak freedom by default”.
> > Now THAT guy must be out of his mind :)
>
> He could be, I havent
On Monday, 27 November 2017 at 15:56:09 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
wrote:
Then watch Herb’s Sutter recent talk “Leak freedom by
default”. Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt
Btw, it would improve the discourse if people tried to
distinguish between language constructs and library constructs...
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
wrote:
Then watch Herb’s Sutter recent talk “Leak freedom by default”.
Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently used,
it is a last resort,
atomic_shared_pointer is
On Monday, 27 November 2017 at 07:03:01 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky
wrote:
Last time I check shared_ptr can be safely shared across
threads, hence RC is takling synchronization and most likely
atomics since locks won’t be any
On Monday, 27 November 2017 at 10:13:41 UTC, codephantom wrote:
But in a discussion about GC, some technical details might
prove to be very useful to those of us following this
discussion.
Precise scanning of pointers makes sense when you have many
cachelines on the GC with no pointers in
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
Current GC in D is shit
Can you elaborate?
"D is totally useless"..."Dlang is a toy in outer space"... "GC
in D is shit" ..
I'm very open minded to these different argument styles, and
occassionaly make use of them myself. But
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
Please stop this flame
There is no flaming.
Current GC in D is shit and all this speaking won't improve
situation.
If so, why are you here? But you are fundamentally wrong. Precise
GC will not bring a general improvement, for
Please stop this flame and make first real step into bringing
precise GC to us.
Current GC in D is shit and all this speaking won't improve
situation.
The PR is not merged although it passed all the tests.
On Monday, 27 November 2017 at 07:09:25 UTC, Ola Fosheim Grostad
wrote:
But it kinda is missing the point that if it only is in a
single thread then it would typically only have only one
assignment. Shared_ptr is for holding a resource not for using
it...
Just to expand a bit on this: What
On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov
[ZombineDev] wrote:
the shared_ptr itself) and you can't opt out of that even if
you're not sharing the shared_ptr with other threads.
Well, the compiler can in theory ellide atomics if it csn prove
that the memory cannot be accessed by
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky
wrote:
Last time I check shared_ptr can be safely shared across
threads, hence RC is takling synchronization and most likely
atomics since locks won’t be any better.
The controlblock can, but it is crazy to use shared_ptr for
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics
which makes RC costly.
No, you dont.
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics
which makes RC costly.
No, you dont.
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics which
makes RC costly.
No, you dont. Nobody in their right mind would do so in C++ as a
general solution.
On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote:
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
wrote:
If all of the code is 100% @safe (not system and not trusted)
you have a different language where write barriers would be
cheaper to implement.
Sadly you can’t
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis
wrote:
It wouldn't work. @safe code and @system code call each other
all the time (using @trusted where necessary), and they freely
exchange stuff that was allocated on the GC heap. [snip]
I see. Fair enough.
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis
wrote:
We can't even have different heaps for immutable and mutable
stuff, because it's very common to construct something as
mutable and then cast it to immutable (either explicitly or
This is easy to fix, introduce a uniquely
On Sunday, November 26, 2017 18:58:04 jmh530 via Digitalmars-d wrote:
> On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
>
> wrote:
> > If all of the code is 100% @safe (not system and not trusted)
> > you have a different language where write barriers would be
> > cheaper to
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
wrote:
If all of the code is 100% @safe (not system and not trusted)
you have a different language where write barriers would be
cheaper to implement.
Sadly you can’t “skip” write barriers in your @system code
because it may run
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
wrote:
Sadly you can’t “skip” write barriers in your @system code
because it may run as part of larger @safe. Which is where they
Well, you can if you carefully lock the gc runtime or if you dont
modify existing scannable pointers
On Sunday, 26 November 2017 at 04:01:31 UTC, jmh530 wrote:
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky
wrote:
A better GC is a great direction. Generational one is not
feasible unless we disallow quite a few of our features.
What about @safe?
If all of the code is 100%
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky
wrote:
A better GC is a great direction. Generational one is not
feasible unless we disallow quite a few of our features.
What about @safe?
On Friday, 24 November 2017 at 07:48:03 UTC, Ola Fosheim Grøstad
wrote:
But I am not sure if Walter's goal is to attract as many users
as possible.
Given all the bullshit bugs I have to deal with, I'm starting to
think it's the opposite.
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
a precise GC will enable data with isolated or immutable
indirections to
be safely moved between threads
I think you could in any case. What precise allows is to copy
object during collection if there is no conservative
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
RAII+stack allocations make sense when I care about WHEN an
object is released and wish to provide some semblance of
control over deallocation (although as Andrei has pointed out
numerous time, you have no idea how many objects
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson
wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your
On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a
short life span. I don't think this fits well
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects
have a short life span. I don't think this fits well with
sensible use of a language like D where
On 11/23/17 02:47, Nordlöw wrote:
On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson wrote:
Thats a linker(?) limitation for OMF (or whatever is the win32 object
file format).
Was just fixed!
What improvements to D's concurrency model is made possible with this
precise GC?
I
On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson
wrote:
Thats a linker(?) limitation for OMF (or whatever is the win32
object file format).
Was just fixed!
What improvements to D's concurrency model is made possible with
this precise GC?
I recall Martin Nowak saying at DConf
On 11/22/17 05:44, Nicholas Wilson wrote:
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in object file
What's wrong?
Thats a linker(?)
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in object file
What's wrong?
On 11/22/17 02:53, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will help
those who affected by it.
It seems
41 matches
Mail list logo
