On 26 May 2010, at 20:00, Greg Parker wrote:
Mac or iPhone?
iPhone device or iPhone simulator?
32-bit Mac or 64-bit Mac?
Sorry for the vagueness. 32 bit mac.
My guess is that (1) you're running on iPhone Simulator or 32-bit Mac, and
(2) you recently added an ivar to MGS_A but did
On 27 May 2010, at 12:53, jonat...@mugginsoft.com wrote:
iPhone device and 64-bit Mac should not have this problem. The compiler and
runtime cooperate to allow the runtime to move the subclass's ivars out of
the way if the superclass grows.
Le 27 mai 2010 à 13:53, jonat...@mugginsoft.com a écrit :
On 26 May 2010, at 20:00, Greg Parker wrote:
Mac or iPhone?
iPhone device or iPhone simulator?
32-bit Mac or 64-bit Mac?
Sorry for the vagueness. 32 bit mac.
My guess is that (1) you're running on iPhone Simulator or
On 27 May 2010, at 14:42, Jean-Daniel Dupas wrote:
Is there no build support to help with these sorts of class dependencies?
Or have I borked my build settings somewhere?
If MGS_B is a subclass of MGS_A , it must import the MGS_A header file (else
the compiler will complain).
If you
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
Moving tempFilePath up the ivar list resolves the problem (though doubtless
creates another).
Moving ivar stderrData into the superclass
Le 26 mai 2010 à 13:40, jonat...@mugginsoft.com a écrit :
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
If I am not mistaken, if your superclass ivar is private (!= protected), it
On 26/05/2010, at 10:13 PM, vincent habchi wrote:
If I am not mistaken, if your superclass ivar is private (!= protected), it
cannot be accessed from its subclasses. Thus, the compiler can choose to
reuse part of the heap dedicated to private variables to implement subclasses
own private
On Wed, May 26, 2010 at 8:13 AM, vincent habchi vi...@macports.org wrote:
Le 26 mai 2010 à 13:40, jonat...@mugginsoft.com a écrit :
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
If
Le 26 mai 2010 à 14:22, Graham Cox a écrit :
I'm pretty sure you are mistaken. If this were even remotely true, object
programming would be impossible.
@private only declares the visibility of an ivar to its subclasses, it does
not give the compiler carte blanche to write over anything it
There's nothing wrong with the ivar declarations - something must be
going wrong at run time. Typically, when an object pointer seems to
point to the wrong object, the prime suspect is memory management. But
it's hard to say for sure, without seeing the relevant code.
The ivar decs look
On 26/05/2010, at 10:41 PM, vincent habchi wrote:
Hmmm... Let's say you have a class A with a private variable priv and b a
pointer to a subclass of A. Is:
[(A *)b priv]
legal?
No. It's not legal syntax for accessing an ivar in any case - square brackets
invoke a method:- [instance
Hi Jonathan
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
I'm not sure what you mean here by overwrite.
@interface Base : NSObject
{
@private
int i;
}
@end
@interface Sub :
On May 26, 2010, at 1:40 PM, jonat...@mugginsoft.com wrote:
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
Are you using this class across module boundaries? E.g. is the base class in
@interface A(MyCategory)
-(void)someMethodWhichLegallyAccessesThePrivateVariablePriv;
@end
That's legal, I can write a category against an already-compiled class without
having the source and without recompiling it and I can access any of the
private variables of that class. So no the
Le 26 mai 2010 à 14:53, Graham Cox a écrit :
On 26/05/2010, at 10:41 PM, vincent habchi wrote:
Hmmm... Let's say you have a class A with a private variable priv and b a
pointer to a subclass of A. Is:
[(A *)b priv]
legal?
No. It's not legal syntax for accessing an ivar in any
Le 26 mai 2010 à 14:53, Graham Cox a écrit :
On 26/05/2010, at 10:41 PM, vincent habchi wrote:
Hmmm... Let's say you have a class A with a private variable priv and b a
pointer to a subclass of A. Is:
[(A *)b priv]
legal?
No. It's not legal syntax for accessing an ivar in any
Le 26 mai 2010 à 15:00, Roland King a écrit :
@interface A(MyCategory)
-(void)someMethodWhichLegallyAccessesThePrivateVariablePriv;
@end
That's legal, I can write a category against an already-compiled class
without having the source and without recompiling it and I can access any of
Le 26 mai 2010 à 15:10, vincent habchi a écrit :
Le 26 mai 2010 à 14:53, Graham Cox a écrit :
On 26/05/2010, at 10:41 PM, vincent habchi wrote:
Hmmm... Let's say you have a class A with a private variable priv and b a
pointer to a subclass of A. Is:
[(A *)b priv]
legal?
No.
On 26/05/2010, at 11:10 PM, vincent habchi wrote:
So, tell me if I'm wrong, but I infer from your answer that whatever I can
do, there is no means for a subclass A' to access any private variable of its
ancestor.
Correct, if class A has not declared an accessor to it, and you haven't added
Le 26 mai 2010 à 15:24, Jean-Daniel Dupas a écrit :
Who knows what a class does when you set an ivar using the accessor. It would
badly break encapsulation principle.
For example, what would append if a NSView subclass change the view frame by
accessing the _frame ivar directly ?
You are
On May 26, 2010, at 6:00 AM, Roland King r...@rols.org wrote:
@interface A(MyCategory)
-(void)someMethodWhichLegallyAccessesThePrivateVariablePriv;
@end
That's legal, I can write a category against an already-compiled
class without having the source and without recompiling it and I can
On 26 May 2010, at 13:55, Uli Kusterer wrote:
On May 26, 2010, at 1:40 PM, jonat...@mugginsoft.com wrote:
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar tempFilePath
gets overwritten.
Are you using this class
On Wed, 26 May 2010 08:28:17 -0400, Sherm Pendley said:
Typically, when an object pointer seems to
point to the wrong object, the prime suspect is memory management.
Agreed. Jonathan, have you tried guard malloc and AUTO_USE_GUARDS?
--
On Wed, 26 May 2010 13:54:17 +0100, Joanna Carter said:
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar
tempFilePath gets overwritten.
I'm not sure what you mean here by overwrite.
@interface Base : NSObject
{
Jonathan Mitchell wrote:
MGSScriptExecutorManager *scriptExecutorManager;
NSString *tempFilePath;
}
@interface MGS_B : MGS_A {
@private
NSData *stderrData;
}
Change the ivars to something like this:
MGSScriptExecutorManager *scriptExecutorManager;
On May 26, 2010, at 6:10 AM, vincent habchi wrote:
So, tell me if I'm wrong, but I infer from your answer that whatever I can
do, there is no means for a subclass A' to access any private variable of its
ancestor.
Not without some nasty tricks (this is native code, so nasty tricks are
Hi Sean
I think you are confusing some similar-sounding words: override and
overwrite (and there's also overload). By overwrite, he means the
memory occupied by one ivar is being unexpectedly written to when
writing to a different ivar.
Yes, I gathered that as the discussion evolved.
On May 26, 2010, at 4:40 AM, jonat...@mugginsoft.com wrote:
A subclass ivar is apparently overwriting a super class ivar.
When an instance of MGS_B sets stderrData the super class ivar
tempFilePath gets overwritten.
Moving tempFilePath up the ivar list resolves the problem (though
Jens,
I think you’re confusing an inaccessible variable with an unused variable.
Those are very different concepts. For example, NSView’s _frame instance
variable is inaccessible from any subclass, but the variable is of course a
crucial part of the view’s state and is accessed by lots of
On May 26, 2010, at 12:04 PM, vincent habchi wrote:
At the same time, I remember having this kind of weird behavior (I mean, one
variable unexpectedly written) when that variable has been (unexpectedly)
released, and its space is reused by some other variable.
That’s when an object on the
30 matches
Mail list logo
