• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: C arrays as __block variables
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C arrays as __block variables


  • Subject: Re: C arrays as __block variables
  • From: John Engelhart <email@hidden>
  • Date: Tue, 29 Jun 2010 19:55:06 -0400

On Sun, Jun 27, 2010 at 12:19 AM, Bill Bumgarner <email@hidden> wrote:

>
> On Jun 26, 2010, at 9:14 PM, Tony Romano wrote:
>
> > That's why I asked for an example of what the op question is
>
> http://lists.apple.com/archives/cocoa-dev/2010/Jun/msg01040.html
>
> > This would seem to imply that a __block variable *can* be a *fixed*
> length
> > array. But when I try to write into such an array inside a block, I get a
> > compile error, "cannot access __block variable of array type inside
> block."
>
> void foo() {
>    __block char barfy[100];
>
>    ^() {
>        char b = barfy[0]; <<<<  error: cannot access __block variable of
> array type inside block
>        b = b;
>    };
> }
>
> void bar() {
>    __block struct angus {
>        char barfy[100];
>    } kangus;
>
>    ^() {
>        char b = kangus.barfy[0];  // compiles fine
>        b = b;
>    };
> }
>
> The reason being that a Block_copy() or [block copy] will cause the __block
> variables to be moved to the heap and, thus, the compiler must know the
> exact size of all variables to be copied when emitting the copy helper.
>

Sorry, could you elaborate on this point?

Specifically, you seem to imply that the compiler does "not know the size"
of "__block char barfy[100];" (from foo()).

Why does the compiler make any meaningful distinction between foo() and
bar()?  And why does wrapping the char array inside a struct cause it to
"work" in bar(), but fail in foo()?

I have yet to dig in to the pedantic details of the standard, but I'm fairly
sure the standard guarantees that:

1) in foo(), sizeof(barfy) == (in bar()) sizeof(kangus) == (in bar())
sizeof(kangus.barfy)
2) in bar(), &kangus == &kangus.barfy == &kangus.barfy[0]

The way I read things, the two examples given are "essentially
indistinguishable semantically" and mean the same thing for all practical
purposes. In fact, off the top of my head, and a cursory glance at the
standard, I can't find anything that makes any meaningful semantic
difference between the two.
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >C arrays as __block variables (From: Matt Neuburg <email@hidden>)
 >Re: C arrays as __block variables (From: Bill Bumgarner <email@hidden>)
 >Re: C arrays as __block variables (From: Tony Romano <email@hidden>)
 >Re: C arrays as __block variables (From: Bill Bumgarner <email@hidden>)
 >Re: C arrays as __block variables (From: Tony Romano <email@hidden>)
 >Re: C arrays as __block variables (From: Kyle Sluder <email@hidden>)
 >Re: C arrays as __block variables (From: Tony Romano <email@hidden>)
 >Re: C arrays as __block variables (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Re: using UTF-32 in NSString.
  • Next by Date: Re: [UPDATE] Applications using RegexKitLite no longer being accepted at the AppStore
  • Previous by thread: Re: C arrays as __block variables
  • Next by thread: Re: C arrays as __block variables
  • Index(es):
    • Date
    • Thread