Escaping the Tyranny of the GC: std.rcstring, first blood

[Andrei Alexandrescu via Digitalmars-d]

On 9/24/14, 3:34 PM, Manu via Digitalmars-d wrote:
> On 25 September 2014 07:17, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 9/24/14, 1:15 PM, Manu via Digitalmars-d wrote:
>>>
>>> Something like (whatever syntax you like):
>>>
>>> int^ rcInt; // refcounted pointer to an int
>>> MyStruct^ rcStruct; // refcounted pointer to a struct
>>> MyStruct s; // normal value-type struct, but if the struct has
>>> opInc/opDec, the RC handling code in the compiler can implicitly
>>> generate calls to opInc/opDec on assignment, which will allow the
>>> struct to manage itself.
>>
>>
>> You're getting confused here, postblit and destructor take care of that.
>
> No they don't. It's not a ref counting mechanism, the compiler can't
> elide those calls.

It can.

> It's what I use now, and it's as good at C++, but we can do much
> better than that.

D's copy semantics are different from C++'s.

>>> Not sure how to express an RC dynamic array... int[^] rcArray? Anyway,
>>> syntax is whatever it is, I think this approach is what makes sense to
>>> me though.
>>
>>
>> Whatever syntax I like? Awesome! How about:
>>
>> RefCounted!int rcInt; // refcounted pointer to an int
>> RefCounted!MyStruct rcStruct; // refcounted pointer to a struct
>> RefCounted!(int[]) rcArray; // refcounted array
>>
>> The irony is the first two already work with the semantics you need, but
>> apparently I've had difficulty convincing you to try them and report back.
>> My work on RCString has also gone ignored by you, although it's exactly
>> stuff that you're asking for.
>
> It all feels backwards to me.

So it's not whatever syntax I like? Make up your mind.

> You've completely alienated me from the
> discussion. I've given up, but I am watching with interest.

How do you mean that?

> I'm not interested in a library solution until I know if, and how the
> compiler will optimise it... in which case it's not a library solution
> anymore, so why make the implementation a lib?

This can't be serious. So you're not looking at any prototype because 
it's not optimized up to wazoo?

> @nogc users will use this stuff EXCLUSIVELY. There is already more
> than enough attribution in D, I *WILL NOT* wrap everything in my
> program with RefCounted!(). I will continue to invent my own solutions
> in every instance, and we will live the same reality as C++; where
> everyone has their own implementations, and none of them are
> compatible.

But in C++ you'd use shared_ptr<T> all the time. Your position is 
completely irrational. Frankly it looks you're bullshitting your way 
through the whole conversation. Whenever anyone puts you in the position 
of making a positive contribution, you run away for something else to 
whine about.

> Call it a bikeshed, whatever. I'm certain this is the practical reality.
>
> I have tried RefCounted extensively in the past. Mangling my types
> like that caused lots of problems, heaps of is(T == RefCounted!U, U)
> started appearing throughout my code, and incompatibility with
> existing libraries.

Existing libraries won't be helped by adding new functions.

What issues did you have with RefCounted? Why do you keep on coming back 
to "it's mangling my types"? Why do you need heaps of is(...)? What is 
it that you're trying to solve, that only a solution you're unable to 
specify can fix?

> Perhaps the most annoying thing about a library implementation though
> is the debuginfo baggage. It's extremely frustrating dealing with
> things that are wrapped up like RefCounted while debugging.

How do you debug code using shared_ptr?

> You can't
> evaluate the thing anymore, stepping through your code leads you
> through countless library stubs and indirections. You lose the ability
> to just read a symbol name without fuss, you need to make your
> callstack window half the screen wide to see what you're looking at.
>
> I'm also not convinced meaningful refcounting can be implemented
> before we have scope(T) working properly. I think we should be
> addressing that first.

That may as well be true.


Andrei