On 2/5/14, 10:38 AM, Namespace wrote:
> How would look the syntax for creating a RC slice?
> int[] arr = new int[100];
> or
> somewhat ugly as RCSlice!int arr = new int[100];
> ?
> Or (as I fear) RCSlice!int arr = RCSlice!int(100); ?

Just call a function! The "new" syntax for arrays is syntactically bankrupt anyway (can't distinguish between static and dynamic arrays). A historical mistake.

Andrei

On Wednesday, 5 February 2014 at 18:42:55 UTC, Andrei Alexandrescu wrote:
> On 2/5/14, 10:38 AM, Namespace wrote:
>> How would look the syntax for creating a RC slice?
>> int[] arr = new int[100];
>> or
>> somewhat ugly as RCSlice!int arr = new int[100];
>> ?
>> Or (as I fear) RCSlice!int arr = RCSlice!int(100); ?
>
> Just call a function! The "new" syntax for arrays is syntactically bankrupt anyway (can't distinguish between static and dynamic arrays). A historical mistake.
>
> Andrei

Thanks. So I can still rely on my own code. :)

On Wednesday, 5 February 2014 at 18:33:54 UTC, Andrei Alexandrescu wrote:
> Phobos needs to be able to return allocated memory without creating litter. With RCSlice!T the ownership is passed back to the user. The user can continue tracking it by using reference counting built into RCSlice, or make the object "immortal" by calling .toGC against it.

Would it be possible to use RCSlice for all reference counting? I.e. that a reference counter for a struct would be a RCSlice of fixed length 1?

If so then maybe it would be nice, but with a different name.

On Wednesday, 5 February 2014 at 18:45:28 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 5 February 2014 at 18:33:54 UTC, Andrei Alexandrescu wrote:
>> Phobos needs to be able to return allocated memory without creating litter. With RCSlice!T the ownership is passed back to the user. The user can continue tracking it by using reference counting built into RCSlice, or make the object "immortal" by calling .toGC against it.
>
> Would it be possible to use RCSlice for all reference counting? I.e. that a reference counter for a struct would be a RCSlice of fixed length 1?
>
> If so then maybe it would be nice, but with a different name.

shared_ptr? ;) Welcome to C++.

On Wednesday, 5 February 2014 at 18:51:05 UTC, Namespace wrote:
> On Wednesday, 5 February 2014 at 18:45:28 UTC, Ola Fosheim Grøstad wrote:

>>
>> If so then maybe it would be nice, but with a different name.
>
> shared_ptr? ;) Welcome to C++.

Yes! :-)

Even better: Let the length be 0 for weak pointers after the resource is released. Not so bad, actually.

On Wednesday, 5 February 2014 at 18:33:54 UTC, Andrei Alexandrescu wrote:
> Phobos needs to be able to return allocated memory without creating litter. With RCSlice!T the ownership is passed back to the user. The user can continue tracking it by using reference counting built into RCSlice, or make the object "immortal" by calling .toGC against it.

Ok, clear. It will work then as far as I can see.

But I am surprised this is considered a #1 issue to address. I have never been worried by lack of control over generated garbage in Phobos - it was the other way around, worries about control of how it is allocated.

So yes, this is likely to solve issue you have mentioned but does not seem to be of any interest to me.

On Wednesday, 5 February 2014 at 18:26:38 UTC, Andrei Alexandrescu wrote:
> Why? The RC object has a different layout, so it may as well have a different type.

It also has different usage requirements, so it should have a different type.

BTW so should GC vs borrowed pointers.

On Wednesday, 5 February 2014 at 18:25:31 UTC, Andrei Alexandrescu wrote:
> Allow people to clean up memory allocated by Phobos.

A better solution would be for Phobos to allocate less memory. Instead of returning strings, accept output ranges that receive it. Make slices work as output ranges well with control over growing.

(We can still offer the simple string returning functions for convenience)

Would it not be possible to add an "int rc" to the internal Array struct? So that int[] arr = [1, 2, 3]; is ref counted per default? If you want it to be immortal, call toGC(arr) or with UFCS arr.toGC() which set the rc to uint.max / 2?
That would keep the nice syntax. :)

Am Wed, 05 Feb 2014 17:24:44 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> You could put in a function pointer to a deallocator (c-malloc, QT, GTK or some other library deallocator etc) and other kind of meta information that makes you able to treat reference counting in a uniform manner even for external resources.

Now that sounds interesting. That's an area where AGC typically doesn't kick in, because it can only see the small amount of memory used on the D wrapper side.

-- 
Marco