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@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
