undefined | Better HN

0 pointssaagarjha7y ago0 comments

> Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access.

Well, that's the beauty of upgrading to ARC: your declaration syntax doesn't need to change; usually it just means that you can drop a bunch of autoreleases in your codebase.

I read your blog post, where you mention this snippet of code being optimized in an odd way, printing "1 2" in Clang:

  int main() {
    int *p = (int*)malloc(sizeof(int));
    int *q = (int*)realloc(p, sizeof(int));
    *p = 1;
    *q = 2;
    if (p == q)
      printf("%d %d\n", *p, *q);
  }

Of course, when you have odd things like this happen you're reaching down into undefined behavior, and then all bets are off.

Really, I you're just focusing on performance too much and neglecting the fact that ARC isn't there for increasing the performance of your code: it's there so that you can program in a manner that's more safe. Sure, it's easy to manage memory manually, until that one time you double free and SIGSEGV.

0 comments

mpweiher7y ago

> drop a bunch of autoreleases

And add a bunch of allocs, which I find less useful because they don't really communicate intent, whereas the autoreleases usually do. Also, in my code-base, autoreleases are less than 0.5% of the total code, and that includes a lot of legacy code.

In fact, after creating a macro for creating class-side convenience creation methods along with initializers in one go, I could probably drop the use to nearly zero. (The convenience creation methods are always +fooXYZ { return [[[self alloc] initXYZ] autorelease]; } so very automatable).

> undefined behavior

Yes, that's the excuse. It's a bad excuse.

> focusing on performance

Well, performance is my specialty. It also has the advantage of more likely giving you actual data, rather than vague feelings.

> that one time you double free and SIGSEGV

I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

saagarjhaOP7y ago

> Yes, that's the excuse. It's a bad excuse.

I'm amazed that you find this to be a bad excuse, since it's what all optimizing compilers rely on to produce performant code.

> I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

The code crashes because you violated an invariant at some point of program execution. The way the C-style languages work, it's legal to crash (or not) at a place that isn't necessarily the place where the undefined behavior happens (interestingly, not only does this have to be after: it can also happen before the buggy code executes, due to reordering, pipelining and such). This is one of the guarantees you get "for free" by using a safer language such as Swift.

mpweiher7y ago

> [undefined behavior for optimization]

Yes, I am aware that that is the excuse. It still is a terrible excuse.

> because you violated an invariant at some point of program execution.

Not true. The code in question is a callback, so my code is getting called by Apple code, and ARC dereferences a pointer it has no business de-referencing.

May I remind you that the code that crashed due to a segfault was

    {
       return 0;
    }

Also, if you think "You have violated something, for which we will give you no diagnostic, and therefore we feel free to crash you at some random other place in the program that has nothing to do with the place where the alleged violation took place, again with no diagnostics" is reasonable...well, could I interest you in purchasing a bridge in New York? Or some Nevada oceanfront real estate?

And no, you don't need a "safer" language like Swift, you just need to not go for the crazy modifications the optimizer writers pushed into the C standard.

1 more reply

j / k navigate · click thread line to collapse

0 pointssaagarjha7y ago0 comments

> Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access.

Well, that's the beauty of upgrading to ARC: your declaration syntax doesn't need to change; usually it just means that you can drop a bunch of autoreleases in your codebase.

I read your blog post, where you mention this snippet of code being optimized in an odd way, printing "1 2" in Clang:

  int main() {
    int *p = (int*)malloc(sizeof(int));
    int *q = (int*)realloc(p, sizeof(int));
    *p = 1;
    *q = 2;
    if (p == q)
      printf("%d %d\n", *p, *q);
  }

Of course, when you have odd things like this happen you're reaching down into undefined behavior, and then all bets are off.

0 comments

mpweiher7y ago

> drop a bunch of autoreleases

> undefined behavior

Yes, that's the excuse. It's a bad excuse.

> focusing on performance

Well, performance is my specialty. It also has the advantage of more likely giving you actual data, rather than vague feelings.

> that one time you double free and SIGSEGV

I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

saagarjhaOP7y ago

> Yes, that's the excuse. It's a bad excuse.

I'm amazed that you find this to be a bad excuse, since it's what all optimizing compilers rely on to produce performant code.

> I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

mpweiher7y ago

> [undefined behavior for optimization]

Yes, I am aware that that is the excuse. It still is a terrible excuse.

> because you violated an invariant at some point of program execution.

Not true. The code in question is a callback, so my code is getting called by Apple code, and ARC dereferences a pointer it has no business de-referencing.

May I remind you that the code that crashed due to a segfault was

    {
       return 0;
    }

And no, you don't need a "safer" language like Swift, you just need to not go for the crazy modifications the optimizer writers pushed into the C standard.

1 more reply

j / k navigate · click thread line to collapse