I now think that what I am seeing is a minor parsing sort of issue within
the compiler (gcc 4.2) when mixing idSomeProtocol 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
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'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
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 idFrameProtocol frame. If I attempt to call a
getter for the object I get the following compiler error:
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
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
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, and
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
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 the
On Mon, Nov 8, 2010 at 8:37 AM, Jonny Taylor j.m.tay...@durham.ac.uk 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
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
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
On Mon, Nov 8, 2010 at 10:53 AM, Jonny Taylor j.m.tay...@durham.ac.uk 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
On Mon, Nov 8, 2010 at 10:53 AM, Jonny Taylor j.m.tay...@durham.ac.uk 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
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 idSomeProtocol with blocks.
The more fundamental problem is that gcc C++ does not fully support blocks,
period.
--
Greg Parker
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 idSomeProtocol with blocks.
The more fundamental problem is that gcc C++ does not fully support blocks,
period.
Indeed, as soon as it gets
16 matches
Mail list logo
