I'm new at this too, so perhaps I am completely off here. My guess is that it
isn't the const that is messing this up, but the non-class type. The problem I
see is that "frame" is a pointer to an objc_object and objc_objects aren't the
same as NSObjects (but, like I said, I'm new, so maybe they
On Tue, 9 Nov 2010 12:08:57 +, Jonny Taylor said:
>For what it's worth, my bug has been closed with the comment "Please
>upgrade to the LLVM Compiler when Xcode 4 is released". Hopefully it
>won't be too long now, and if all the blocks business is sorted that
>will make me very happy!
You can
>>> I now think that what I am seeing is a minor parsing sort of issue within
>>> the compiler (gcc 4.2) when mixing id with blocks.
>> The more fundamental problem is that gcc C++ does not fully support blocks,
>> period.
> Indeed, as soon as it gets a sniff of c++ near a block things start to
On 8 Nov 2010, at 20:11, Greg Parker wrote:
>> I now think that what I am seeing is a minor parsing sort of issue within
>> the compiler (gcc 4.2) when mixing id with blocks.
> The more fundamental problem is that gcc C++ does not fully support blocks,
> period.
Indeed, as soon as it gets a snif
On Nov 8, 2010, at 10:53 AM, Jonny Taylor wrote:
> I now think that what I am seeing is a minor parsing sort of issue within the
> compiler (gcc 4.2) when mixing id with blocks.
The more fundamental problem is that gcc C++ does not fully support blocks,
period.
--
Greg Parker gpar...@app
> On Mon, Nov 8, 2010 at 10:53 AM, Jonny Taylor wrote:
>>// Both these have errors: "request for member 'frameNumber'
>> in 'm', which is of non-class type 'objc_object* const'"
>>// when compiled as ObjC++ (.mm file).
>
> Aha, this is an important point. That's w
On Mon, Nov 8, 2010 at 10:53 AM, Jonny Taylor wrote:
> // Both these have errors: "request for member 'frameNumber'
> in 'm', which is of non-class type 'objc_object* const'"
> // when compiled as ObjC++ (.mm file).
Aha, this is an important point. That's why I didn
> I'm new at this too, so perhaps I am completely off here. My guess is that it
> isn't the const that is messing this up, but the non-class type. The problem
> I see is that "frame" is a pointer to an objc_object and objc_objects aren't
> the same as NSObjects (but, like I said, I'm new, so may
Thankyou everybody for your help (and patience!) with this one. I have indeed
been making some wrong assumptions and as I result much of what I was writing
was incorrect. From the various helpful replies I have received, I have (I
hope!) got a much clearer understanding of what is and isn't goin
On Mon, Nov 8, 2010 at 8:37 AM, Jonny Taylor wrote:
> I'm afraid I'm not sure if I understand exactly what you're asking. I would
> like to be able access the "frame number" property (which is in fact stored
> as a variable within the class, and is fixed soon after instantiation) in
> spite of
On Nov 8, 2010, at 9:04 AM, Jonny Taylor wrote:
> In this particular case I don't have much choice in the matter - the standard
> behaviour of blocks is to provide 'const' access to variables declared
> outside the block (and with good reason I think). In the example I gave, I
> want to access
In this particular case I don't have much choice in the matter - the standard
behaviour of blocks is to provide 'const' access to variables declared outside
the block (and with good reason I think). In the example I gave, I want to
access the property from within a block. I can work around it as
My question is why do you need to have a 'const' pointer.
On Nov 8, 2010, at 8:37 AM, Jonny Taylor wrote:
> I'm afraid I'm not sure if I understand exactly what you're asking. I would
> like to be able access the "frame number" property (which is in fact stored
> as a variable within the class,
I'm afraid I'm not sure if I understand exactly what you're asking. I would
like to be able access the "frame number" property (which is in fact stored as
a variable within the class, and is fixed soon after instantiation) in spite of
the fact that I only have a 'const' pointer to the object at
It might be useful to know what you expect to get from the const reference in
the first place? Primarily because I highly suspect that it is not necessary to
ensure the semantics that you desire.
On Nov 8, 2010, at 4:59 AM, Jonny Taylor wrote:
> I have encountered what I presume is a common new
I have encountered what I presume is a common newcomer's problem, but I haven't
had any luck with google (maybe I'm using the wrong search terms?). Suppose I
have a const id, e.g. "const id frame". If I attempt to call a
getter for the object I get the following compiler error:
request for membe
16 matches
Mail list logo
