| |
| Posted by Walter Bright in reply to Adam D Ruppe | PermalinkReply |
|
Walter Bright
Posted in reply to Adam D Ruppe
| On 10/29/2022 5:18 AM, Adam D Ruppe wrote:
> On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
>> I've pointed out the problems with two hierarchies of pointers many times.
>
> D already has several kinds of pointers. T*, const(T)*, shared(T)*. I don't see how unmanaged(T*) is any different.
Consider:
strcpy(char* p, const(char)* q)
Now consider managed:
strcpy(char* p, const(char)* q)
strcpy(char* p, managed(const(char)*) q)
strcpy(managed(char*) p, const(char)* q)
strcpy(managed(char*) p, managed(const(char)*) q)
It's quite different.
> In fact, I sketched up some thoughts i might put in the blog monday but the short of it is you could:
>
> * -ptrcheck=[none|barrier] argument to the compiler, similar to how -checkaction and -boundscheck can be modified.
>
> * all pointer writes assumed to be barriered except ones marked raw/unmanaged/whatever, which is a qualifier similar to const and shared
>
> * the raw pointer would essentially be struct raw(T) { T it; alias it this; void opAssign(T rhs) { barrier(); it = rhs; } }
>
> * possible optimizations would be eliding the barrier in cases like `a = a[1 .. $]` because you know - thanks to the bounds check - that this refers to the same memory block anyway and is thus irrelevant to the GC wrt marking. I guess it can be trouble if it wants to move tings in the middle of the slice operation though.
>
>
> I'm not convinced this is impossible.
It's not impossible. It's more like what is the cost/benefit.
> (btw im also not convinced it is necessary, i think D's gc is good enough as it is.)
So do I. Isn't it ironic that people complain about D because it has a GC, and complain about D because the GC does not slow down non-GC code? I'm terrible at marketing.
|