mccallum@gnu.ai.mit.edu)Date: Generated at 2025-02-11 22:18:53 +0100
Copyright: (C) 1995, 1996, 1998 Free Software Foundation, Inc.
- Declared in:
- Foundation/NSObject.h
NSObject is the root class (a root
class is a class with no superclass) of the GNUstep
base library class hierarchy, so all classes normally
inherit from NSObject. There is an
exception though: NSProxy (which is
used for remote messaging) does not inherit from
NSObject.
Unless you are really sure of what you are doing,
all your own classes should inherit (directly or
indirectly) from NSObject (or in
special cases from NSProxy).
NSObject provides the basic common
functionality shared by all GNUstep classes
and objects.
The essential methods which must be implemented by all
classes for their instances to be usable within
GNUstep are declared in a separate protocol, which
is the NSObject protocol. Both
NSObject and NSProxy
conform to this protocol, which means all objects
in a GNUstep application will conform to this protocol
(btw, if you don't find a method of
NSObject you are looking for in this
documentation, make sure you also look into
the documentation for the NSObject
protocol).
Theoretically, in special cases you might
need to implement a new root class. If you do, you
need to make sure that your root class conforms (at
least) to the NSObject protocol,
otherwise it will not interact correctly with the
GNUstep framework. Said that, I must note that I
have never seen a case in which a new root class is
needed.
NSObject is a root class, which implies
that instance methods of NSObject are
treated in a special way by the Objective-C
runtime. This is an exception to the normal way
messaging works with class and instance methods:
if the Objective-C runtime can't find a class method for
a class object, as a last resort it looks for an instance
method of the root class with the same name, and
executes it if it finds it. This means that
instance methods of the root class (such as
NSObject) can be performed by class
objects which inherit from that root class ! This
can only happen if the class doesn't have a class
method with the same name, otherwise that method -
of course - takes the precedence. Because of this
exception, NSObject 's instance
methods are written in such a way that they work
both on NSObject 's instances and on
class objects.
NSDefaultMallocZone()
as the zone argument.
Memory for an instance of the receiver is
allocated; a pointer to this newly created
instance is returned. All instance variables are
set to 0. No initialization of the instance is
performed apart from setup to be an instance of
the correct class: it is your responsibility to
initialize the instance by calling an
appropriate init method. If you
are not using ARC, it is also your responsibility to
make sure the returned instance is destroyed when
you finish using it, by calling the
release method to destroy the
instance directly, or by using
autorelease and autorelease pools.
You do not normally need to override this method in subclasses, unless you are implementing a class which for some reasons silently allocates instances of another class (this is typically needed to implement class clusters and similar design schemes).
If you have turned on debugging of object allocation
(by calling the GSDebugAllocationActive
function), this method will also update the
various debugging counts and monitors of
allocated objects, which you can access using
the GSDebugAllocation... functions.
if (self == [classname class])
conditional to check whether the method is
being called for a subclass. NO otherwise.
YES if the receiver is
aClass or a subclass of aClass.
This method is a short-hand for alloc followed by init, that is,
NSObject *object = [NSObject new];
is exactly the same as
NSObject *object = [[NSObject alloc] init];
This is a general convention: all
new... methods are supposed to return
a newly allocated and initialized instance, as would be
generated by an alloc method
followed by a corresponding init...
method. Please note that if you are not using
ARC, this means that instances generated by the
new... methods are not autoreleased,
that is, you are responsible for releasing
(autoreleasing) the instances yourself.
So when you use new you typically do
something like:
NSMutableArray *array = AUTORELEASE
([NSMutableArray new]);
You do not normally need to override new
in subclasses, because if you override
init (and optionally
allocWithZone: if you really need),
new will automatically use your
subclass methods.
You might need instead to define new
new... methods specific to your
subclass to match any init...
specific to your subclass. For example, if your
subclass defines an instance method
initWithName:
it might be handy for you to have a class method
newWithName:
which combines alloc and
initWithName:. You would implement it
as follows:
+ (id) newWithName: (NSString
*)aName {return [[self alloc] initWithName:
aName];}
YES, otherwise it should return
NO. Note: This method is only reliable
when using the GNUstep runtime. If you require
compatibility with the GCC runtime, you must
also implement
-forwardInvocation:
with equivalent semantics. This will be considerably
slower, but more portable.
YES, otherwise it
should return NO. Note: This method is
only reliable when using the GNUstep runtime. If you
require compatibility with the GCC runtime, you
must also implement
-forwardInvocation:
with equivalent semantics. This will be considerably
slower, but more portable.
[self class] (no substitution).
You should normally call the superclass implementation of this method when you override it in a subclass, or the memory occupied by your object will not be released.
NSObject 's implementation of this
method destroys the receiver, by returning the
memory allocated to the receiver to the system.
After this method has been called on an instance,
you must not refer the instance in any way, because
it does not exist any longer. If you do, it is a bug
and your program might even crash with a segmentation
fault.
If you have turned on the debugging facilities for
instance allocation, NSObject 's
implementation of this method will also
update the various counts and monitors of
allocated instances (see the
GSDebugAllocation... functions for
more info).
Normally you are supposed to manage the memory
taken by objects by using the high level interface
provided by the retain,
release and autorelease
methods (or better by the corresponding macros
RETAIN, RELEASE and
AUTORELEASE), and by autorelease
pools and such; whenever the release/autorelease
mechanism determines that an object is no
longer needed (which happens when its retain count
reaches 0), it will call the dealloc
method to actually deallocate the object. This
means that normally, you should not need to call
dealloc directly as the gnustep base
library automatically calls it for you when the
retain count of an object reaches 0.
Because the dealloc method will be
called when an instance is being destroyed, if
instances of your subclass use objects or
resources (as it happens for most useful
classes), you must override
dealloc in subclasses to release all
objects and resources which are used by the
instance, otherwise these objects and resources
would be leaked. In the subclass implementation,
you should first release all your subclass specific
objects and resources, and then invoke super's
implementation (which will do the same,
and so on up in the class hierarchy to
NSObject 's implementation, which
finally destroys the object). Here is an example
of the implementation of dealloc for a
subclass whose instances have a single instance
variable name which needs to be
released when an instance is deallocated:
- (void) dealloc {RELEASE (name);
[super dealloc];}
dealloc might contain code to release
not only objects, but also other resources, such as
open files, network connections, raw memory
allocated in other ways, etc.
If you have allocated the memory using a non-standard
mechanism, you will not call the superclass
(NSObject) implementation of the method as you
will need to handle the deallocation specially.
In some circumstances, an object may wish
to prevent itself from being deallocated, it can do
this simply be refraining from calling the
superclass implementation.
nil indicates that forwarding should
not take place. The default implementation of this
returns nil, but care should be taken
when subclassing NSObject subclasses and overriding
this method that the superclass implementation is
called if returning nil. Note: This
method is only reliable when using the GNUstep
runtime and code compiled with clang. If you
require compatibility with GCC and the GCC runtime,
you must also implement
-forwardInvocation:
with equivalent semantics. This will be considerably
slower, but more portable.
nil
if given a null selector.
self.
- Declared in:
- Foundation/NSObject.h
Whenever either -autorelease or -release is called, the contents of any autorelease pools will be checked to see if there are more outstanding release operations than the objects retain count. In which case an exception is raised to say that the object is released too many times.
Beware, since this feature entails examining all active autorelease pools every time an object is released or autoreleased, it can cause a massive performance degradation... it should only be enabled for debugging.
When you are having memory allocation problems, it may make more sense to look at the memory allocation debugging functions documented in NSDebug.h, or use the NSZombie features.
- Declared in:
- Foundation/NSObject.h
- Declared in:
- Foundation/NSObject.h
- Declared in:
- Foundation/NSObject.h
- Declared in:
- Foundation/NSObject.h
- Declared in:
- Foundation/NSObject.h
YES if the object's content is
still valid. The caller must call
-endContentAccess
once for every call to
-beginContentAccess
;
YES if the contents of the
object have been discarded, either via a call to
-discardContentIfPossible
while the object is not in use, or by some
implementation dependent mechanism.
- Declared in:
- Foundation/NSObject.h
- Declared in:
- Foundation/NSObject.h
YES if the receiver conforms
to the specified protocol.
YES if the argument is of
another class. For example, if you define a number
class that returns YES if the argument
is a string representation of the number, then this will
break because the string will not recognise your
object as being equal to itself. If two objects are
equal, then they must have the same hash value,
however equal hash values do not imply equality.
YES if the receiver is an
instance of the class, an instance of the
subclass, or (in the case of proxies), an
instance of something that can be treated as an
instance of the class.
YES if the receiver is an
instance of the class or (in the case of proxies),
an instance of something that can be treated as an
instance of the class. Calling this method is
rarely the correct thing to do. In most cases, a
subclass can be substituted for a superclass, so
you should never need to check that an object is really
an instance of a specific class and not a subclass.
YES if the receiver is a
proxy, NO otherwise. The default
implementation of this method in NSObject
returns NO, while the implementation
in NSProxy returns YES.
YES if the object can respond
to messages with the specified selector. The default
implementation in NSObject returns
YES if the receiver has a method
corresponding to the method, but other
classes may return YES if they can
respond to a selector using one of the various
forwarding mechanisms.
- Declared in:
- Foundation/NSObject.h
- Conforms to:
- NSCoding