On Tue, 04 Feb 2014 14:31:13 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/4/14, 11:28 AM, Steven Schveighoffer wrote:
>> Where you have to be cognizant is avoiding cycles. Plain and simple. And
>> it's not that difficult.
>
> Do you have evidence to back that up?

Does personal experience count? I can say that the main project I have worked on in Objective-C uses manual reference counting, and when I have done newer, but shorter/smaller, projects in ARC, it is much much easier to deal with. Maybe my point of reference is tainted :)

If you use xcode to add member variables, it usually chooses the correct attributes for them (weak or not).

But the code the compiler generates for ARC is pretty good. It has quirky rules for naming methods and how you have to return objects (either autorelease or retained), and will not let you do the wrong thing. You also can't do ANY manual memory management in ARC code, it fails to compile.

Trickier aspects are dealing with C structs, which are NOT reference counted, so you have to deal with those manually using malloc/free (not really different from D).

I will say that it really helps to have an understanding of how ARC is actually implemented in the compiler (that is, the process it goes through to add/elide reference increments and decrements).

-Steve

On Tuesday, 4 February 2014 at 19:28:08 UTC, Steven Schveighoffer wrote:
> Where you have to be cognizant is avoiding cycles. Plain and simple. And it's not that difficult. The compiler takes care of the rest. It's somewhat magical I suppose :) Managing your autorelease pools can make a difference, but is not necessarily critical.
>

My experience is that, just like null reference, it is highly dependent on the type of code you are facing.

Typically, you'll have trouble with complex graph of objects.

On Tue, 04 Feb 2014 15:10:48 -0500, deadalnix <deadalnix@gmail.com> wrote:

> On Tuesday, 4 February 2014 at 19:28:08 UTC, Steven Schveighoffer wrote:
>> Where you have to be cognizant is avoiding cycles. Plain and simple. And it's not that difficult. The compiler takes care of the rest. It's somewhat magical I suppose :) Managing your autorelease pools can make a difference, but is not necessarily critical.
>>
>
> My experience is that, just like null reference, it is highly dependent on the type of code you are facing.
>
> Typically, you'll have trouble with complex graph of objects.

This is very true. I have only dealt with acyclic (except for parent pointers) graphs or linked-lists.

For specialized cases, you will have to NULL out the pointers to/from a node that has to be deleted (essentially a manual delete).

But it works VERY well for linked-lists/queues. My app is I/O intensive, so I have a lot of that.

-Steve

On 02/01/2014 07:57 PM, Adam Wilson wrote:
> On TIOBE, there are three non-GC languages in the entire
> top 20 (C, C++, Obj-C) the rest feature a non-ARC GC of some form.

Add "Pascal" and "Delphi/Object Pascal" to that.

Le 04/02/2014 04:30, Manu a écrit :
> On 4 February 2014 12:59, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 2/3/14, 5:51 PM, Manu wrote:
>
>         I'd have trouble disagreeing more; Android is the essence of why
>         Java
>         should never be used for user-facing applications.
>         Android is jerky and jittery, has random pauses and lockups all the
>         time, and games on android always jitter and drop frames. Most
>         high-end
>         games on android now are written in C++ as a means to mitigate that
>         problem, but then you're back writing C++. Yay!
>         iOS is silky smooth by comparison to Android.
>
>
>     Kinda difficult to explain the market success of Android.
>
>
> I think it's easy to explain.
> 1. It's aggressively backed by the biggest technology company in the world.
> 2. It's free for product vendors.
> 3. For all product vendors at the curve of Android's success, it
> presented a realistic and well supported (by Google) competition to
> Apple, who were running away with the industry. Everybody had to compete
> with Apple, but didn't have the resources to realistically compete on
> their own. Nokia for instance were certainly in the best position to
> produce serious competition, but they fumbled multiple times. I suspect
> Google won because they're Google, and it is free.
>
> Even Microsoft failed. C# is, for all intents and purposes, the same as
> Java, except it's even better. If Java was a significant factor in
> Android's success, I'd argue that WindowsMobile should have been equally
> successful.
> I think it's safe to say, that's not the case.
> Personally, I suspect that Java was actually a barrier to entry in early
> Android, and even possibly the reason that it took as it did for Android
> to take root.
> It's most certainly the reason that Android had absolutely no games on
> it for so many years. They eventually released the NDK, and games
> finally appeared. There were years between Angry Birds success in
> iPhone, and any serious games appearing on Android.
> There were years where if you wanted to play games in your mobile
> device, you had to get an iDevice. It's finally levelled now that the
> indisputable success of Android is absolute (and the NDK is available).

I work almost every day on android with NDK and Qt. Tools still poor and there is a lot of issues. I found one critical last week in the ndk : an error with a python dll causing gdb launch failure, so sometimes you just haven't debugger...

Developing games on such devices can be a real pain, apk can't exceed 50Mo and updating files with the obb package must be done manually.

We never got those kind of difficulties with iOS even at the beginning.

PS : I just buy a Nexus 5 to replace my old Motorola defy, and there is absolutely no pauses everything is perfectly smooth. I had some doubts if it was possible before buying it cause of Java,... No I just think all constructors doesn't delivers good drivers and put completely buggy additional components making the bad reputation of Android.
On my defy I always got bad touch events,... It was a real pain to send an SMS :-{

>
> std.typecons.RefCounted!T
>

Does this work equally well with T being both a value objects (struct) and reference objects (class)?

On Tuesday, 4 February 2014 at 20:29:18 UTC, John J wrote:
> On 02/01/2014 07:57 PM, Adam Wilson wrote:
>> On TIOBE, there are three non-GC languages in the entire
>> top 20 (C, C++, Obj-C) the rest feature a non-ARC GC of some form.
>
> Add "Pascal" and "Delphi/Object Pascal" to that.

And Python, which I believe primarily use ARC and then a weird GC of some form to catch cycles.

On Tuesday, 4 February 2014 at 20:55:30 UTC, Ola Fosheim Grøstad wrote:
> And Python, which I believe primarily use ARC and then a weird GC of some form to catch cycles.

Oh, and PHP too.

On Tuesday, 4 February 2014 at 20:57:28 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 4 February 2014 at 20:55:30 UTC, Ola Fosheim Grøstad wrote:
>> And Python, which I believe primarily use ARC and then a weird GC of some form to catch cycles.
>
> Oh, and PHP too.

Oh, and Perl 5…

On Tuesday, 4 February 2014 at 20:16:20 UTC, Steven Schveighoffer wrote:
> On Tue, 04 Feb 2014 15:10:48 -0500, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 19:28:08 UTC, Steven Schveighoffer wrote:
>>> Where you have to be cognizant is avoiding cycles. Plain and simple. And it's not that difficult. The compiler takes care of the rest. It's somewhat magical I suppose :) Managing your autorelease pools can make a difference, but is not necessarily critical.
>>>
>>
>> My experience is that, just like null reference, it is highly dependent on the type of code you are facing.
>>
>> Typically, you'll have trouble with complex graph of objects.
>
> This is very true. I have only dealt with acyclic (except for parent pointers) graphs or linked-lists.
>
> For specialized cases, you will have to NULL out the pointers to/from a node that has to be deleted (essentially a manual delete).
>
> But it works VERY well for linked-lists/queues. My app is I/O intensive, so I have a lot of that.
>
> -Steve

Yes.

Also, another issue comes up when you share data across threads.

Core can share a cache line in read mode, but can't in write mode. That mean that updating the reference count will cause contention on the cache line (core will have to fight for the cache line ownership). That is why immutability + GC is so efficient in a highly concurrent system, and ref counting would ruin that.