Copyright: (C) 2005 Free Software Foundation, Inc.
nil
pointer for tidiness - we can't
accidentally use a DESTROYED object
later. It also makes sure to set the variable to
nil
before releasing the
object - to avoid side-effects of the
release trying to reference the object
being released through the variable.
This function (macro) is a GNUstep extensions, and it is used to localize static strings. Here is an example of a static string:
NSString *message = @"Hi there";... some code...
NSLog (message);
This string can not be localized using the standard openstep functions/macros. By using this gnustep extension, you can localize it as follows:
NSString *message = GSLocalizedStaticString
(@"Hi there", @"Greeting");... some code... NSLog
(NSLocalizedString (message, @""));
When the tools generate the
Localizable.strings
file from the
source code, they will ignore the
NSLocalizedString
call while they will
extract the string (and the comment) to
localize from the
GSLocalizedStaticString
call.
When the code is compiled, instead, the
GSLocalizedStaticString
call is ignored
(discarded, it is a macro which simply expands
to key
), while the
NSLocalizedString
will actually look up
the string for translation in the
Localizable.strings
file.
Please note that there is currently no macro/function to localize static strings using different tables. If you need that functionality, you have either to prepare the localization tables by hand, or to rewrite your code in such a way as not to use static strings.
nil
. nil
. nil
. This function (macro) is a GNUstep extension.
_(@"My string to translate")
is basically equivalent to
NSLocalizedString(@"My string to
translate", @"")
It is useful when you need to translate an application
very quickly, as you just need to enclose all strings
inside
_()
.
But please note that when you use this macro, you are
not taking advantage of comments for the translator, so
consider using NSLocalizedString
instead when you need a comment.
You may define GS_LOCALISATION_BUNDLE_ID to the bundle
identifier of the bundle which is to provide the
localisation information.
This can be
used when compiling a single file by specifying
something like '-D
GS_LOCALISATION_BUNDLE_ID=$(FRAMEWORK_NAME)'
in your make file.
If this is not defined, the
localisation is provided by your application's
main bundle exactly like the NSLocalizedString
function.
Alternatively you may define GS_LOCALISATION_BUNDLE to be the bundle to be used to prvide the localisation information.
This function (macro) is a GNUstep extension.
__(@"My string to translate")
is exactly the same as
GSLocalizedStaticString(@"My
string to translate", @"")
It is useful when you need to translate an application very quickly. You would use it as follows for static strings:
NSString *message = __(@"Hello there");... more
code... NSLog (_(messages));
But please note that when you use this macro, you are
not taking advantage of comments for the translator, so
consider using
GSLocalizedStaticString
instead when
you need a comment.
Macro to check a defined GNUstep version number (GS_GNUSTEP_V) against the supplied arguments. Returns true if no GNUstep version is specified, or if ADD <= version < REM, where ADD is the version number at which a feature guarded by the macro was introduced and REM is the version number at which it was removed.
The version number arguments are six digit integers where the first two digits are the major version number, the second two are the minor version number and the last two are the subminor number (all left padded with a zero where necessary). However, for convenience you can also use the predefined constants... GS_API_NONE , GS_API_LATEST ,
Also see OS_API_VERSION
NB. If you are changing the API (eg adding a new
feature) you need to control the visibility io the
new header file code using
#if GS_API_VERSION(ADD,GS_API_LATEST)
where ADD
is the
version number of the next minor release after the
most recent one.
As a general principle you
should not change the API with changing
subminor version numbers... as that tends to
confuse people (though Apple has sometimes done
it).
Macro to check a defined OpenStep/OPENSTEP/MacOS-X version against the supplied arguments. Returns true if no version is specified, or if ADD <= version < REM, where ADD is the version number at which a feature guarded by the macro was introduced and REM is the version number at which it was removed.
The version number arguments are six digit integers where the first two digits are the major version number, the second two are the minor version number and the last two are the subminor number (all left padded with a zero where necessary). However, for convenience you can also use any of several predefined constants... GS_API_NONE , GS_API_LATEST , GS_API_OSSPEC , GS_API_OPENSTEP , GS_API_MACOSX
Also see GS_API_VERSION
For OSX compatibility, this macro also supports the use of Apple's symbolic constants for version numbering. Their contants are currently four digit values (two digits for the major version, one for the minor, and one for the subminor).
The Apple compatibility version macros are currently: MAC_OS_X_VERSION_10_0 , MAC_OS_X_VERSION_10_1 , MAC_OS_X_VERSION_10_2 , MAC_OS_X_VERSION_10_3 , MAC_OS_X_VERSION_10_4 , MAC_OS_X_VERSION_10_5 , MAC_OS_X_VERSION_10_6 , MAC_OS_X_VERSION_10_7 , MAC_OS_X_VERSION_10_8 MAC_OS_X_VERSION_10_9
This is a macro designed to minimise the use of memory
allocation and deallocation when you need to
work with a vararg list of objects.
The objects
are unpacked from the vararg list into a 'C' array and
then a code fragment you specify is able to
make use of them before that 'C' array is destroyed.
The firstObject argument is the name of the formal parameter in your method or function which precedes the ',...' denoting variable args.
The code argument is a piece of objective-c
code to be executed to make use of the
objects stored in the 'C' array.
When this
code is called the
unsigned integer '__count' will
contain the number of objects unpacked, and the
pointer '__objects' will point to the unpacked
objects, ie. firstObject followed by
the vararg arguments up to (but not including) the
first nil
.
This is a macro designed to minimise the use of memory
allocation and deallocation when you need to
work with a vararg list of objects.
The objects
are unpacked from the vararg list into two 'C' arrays
and then a code fragment you specify is able
to make use of them before that 'C' array is destroyed.
The firstObject argument is the name of the formal parameter in your method or function which precedes the ',...' denoting variable args.
The code argument is a piece of objective-c
code to be executed to make use of the
objects stored in the 'C' arrays.
When this
code is called the
unsigned integer '__count' will
contain the number of objects unpacked, the pointer
'__objects' will point to the first object in
each pair, and the pointer '__pairs' will point to an
array containing the second halves of the pairs of
objects whose first halves are in '__objects'.
This lets you pack a list of the form 'key,
value, key, value,...' into an array of keys and an
array of values.
NSDebugLLog() is the basic debug logging macro used to display log messages using NSLog() , if debug logging was enabled at compile time and the appropriate logging level was set at runtime.
Debug logging which can be enabled/disabled by defining GSDIAGNOSE when compiling and also setting values in the mutable set which is set up by NSProcessInfo. GSDIAGNOSE is defined automatically unless diagnose=no is specified in the make arguments.
NSProcess initialises a set of strings that are
the names of active debug levels using the
'--GNU-Debug=...' command line argument.
Each command-line argument of that form is removed
from NSProcessInfo
's list of arguments
and the variable part (...) is added to the set. This
means that as far as the program proper is concerned,
it is running with the same arguments as if debugging
had not been enabled.
For instance, to debug the NSBundle class, run your program with '--GNU-Debug=NSBundle' You can of course supply multiple '--GNU-Debug=...' arguments to output debug information on more than one thing.
NSUserDefaults also adds debug levels from the array given by the GNU-Debug key... but these values will not take effect until the +standardUserDefaults method is called... so they are useless for debugging NSUserDefaults itself or for debugging any code executed before the defaults system is used.
To embed debug logging in your code you use the NSDebugLLog() or NSDebugLog() macro. NSDebugLog() is just NSDebugLLog() with the debug level set to 'dflt'. So, to activate debug statements that use NSDebugLog() , you supply the '--GNU-Debug=dflt' argument to your program.
You can also change the active debug levels under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug levels - your program can modify this set.
Two debug levels have a special effect - 'dflt' is the level used for debug logs statements where no debug level is specified, and 'NoWarn' is used to *disable* warning messages.
As a convenience, there are four more logging macros you can use - NSDebugFLog() , NSDebugFLLog() , NSDebugMLog() and NSDebugMLLog() . These are the same as the other macros, but are specifically for use in either functions or methods and prepend information about the file, line and either function or class/method in which the message was generated.
NSWarnLog() is the basic debug logging macro used to display warning messages using NSLog() , if warn logging was not disabled at compile time and the disabling logging level was not set at runtime.
Warning messages which can be enabled/disabled by defining GSWARN when compiling.
You can also disable these messages at runtime by supplying a '--GNU-Debug=NoWarn' argument to the program, or by adding 'NoWarn' to the user default array named 'GNU-Debug'.
These logging macros are intended to be used when the software detects something that it not necessarily fatal or illegal, but looks like it might be a programming error. eg. attempting to remove 'nil' from an NSArray, which the Spec/documentation does not prohibit, but which a well written program should not be attempting (since an NSArray object cannot contain a 'nil').
NB. The 'warn=yes' option is understood by the GNUstep make package to mean that GSWARN should be defined, and the 'warn=no' means that GSWARN should be undefined. Default is to define it.
To embed debug logging in your code you use the NSWarnLog() macro.
As a convenience, there are two more logging macros you can use - NSWarnFLog() , and NSWarnMLog() . These are specifically for use in either functions or methods and prepend information about the file, line and either function or class/method in which the message was generated.
nil
. CLASSNAME must be either NSLock,
NSRecursiveLock or one of their subclasses.
See
[NSLock +newLockAt:]
for details. This macro is intended for code that cannot
insure that a lock can be initialized in thread safe
manner otherwise.
NSLock *my_lock = nil; void function (void) { [GS_INITIALIZED_LOCK(my_lock, NSLock) lock]; do_work (); [my_lock unlock]; }
A Behavior can be seen as a "Protocol with an implementation" or a "Class without any instance variables". A key feature of behaviors is that they give a degree of multiple inheritance.
Behavior methods, when added to a class, override the class's superclass methods, but not the class's methods.
Whan a behavior class is added to a receiver class, not only are the methods defined in the behavior class added, but the methods from the behavior's class hierarchy are also added (unless already present).
It's not the case that a class adding behaviors from another class must have "no instance vars". The receiver class just has to have the same layout as the behavior class (optionally with some additional ivars after those of the behavior class).
This function provides Behaviors without adding any new syntax to the Objective C language. Simply define a class with the methods you want to add, then call this function with that class as the behavior argument.
This function should be called in the +initialize method of the receiver.
If you add several behaviors to a class, be aware that the order of the additions is significant.
An Override can be seen as a "category implemented as a separate class and manually added to the receiver class under program control, rather than automatically added by the compiler/runtime.
Override methods, when added to a receiver class, replace the class's class's methods of the same name (or are added if the class did not define methods with that name).
It's not the case that a class adding overrides from another class must have "no instance vars". The receiver class just has to have the same layout as the override class (optionally with some additional ivars after those of the override class).
This function provides overrides without adding any new syntax to the Objective C language. Simply define a class with the methods you want to add, then call this function with that class as the override argument.
This function should usually be called in the +initialize method of the receiver.
If you add several overrides to a class, be aware that the order of the additions is significant.
YES
), off (NO
) or
test (-1) behavior debugging.
YES
if the
variable was found, NO
otherwise. If it
returns YES
, then the values pointed to
by type, size, and offset
will be set (except where they are null pointers).
nil
.
Create a Class structure for use by the ObjectiveC runtime and return an NSValue object pointing to it. The class will not be added to the runtime (you must do that later using the GSObjCAddClasses() function).
The iVars dictionary lists the instance variable names and their types.
nil
if obj is nil
.
nil
if obj is
nil
.
Prints a message to fptr using the format string provided and any additional arguments. The format string is interpreted as by the NSString formatted initialisers, and understands the '%@' syntax for printing an object.
The data is written to the file pointer in the default CString encoding if possible, as a UTF8 string otherwise.
This function is recommended for printing general log messages. For debug messages use NSDebugLog() and friends. For error logging use NSLog() , and for warnings you might consider NSWarnLog() .
nil
.
nil
if nothing is found.
The dst argument is a pointer to a pointer to a buffer in which the converted data is to be stored. If it is a null pointer, this function discards converted data, and is used only to determine the length of the converted data. If the zone argument is non-nul, the function is free to allocate a larger buffer if necessary, and store this new buffer in the dst argument. It will *NOT* deallocate the original buffer!
The size argument is a pointer to the initial size of the destination buffer. If the function changes the buffer size, this value will be altered to the new size. This is measured in bytes.
The src argument is a pointer to the 16-bit unicode string which is to be converted to 8-bit data.
The slen argument is the length of the 16-bit unicode string which is to be converted to 8-bit data. This is measured in 16-bit characters, not bytes.
The enc argument specifies the encoding type of the 8-bit byte sequence which is to be produced from the 16-bit unicode.
The zone argument specifies a memory
zone in which the function may allocate a
buffer to return data in. If this is nul, the
function will fail if the originally supplied
buffer is not big enough (unless dst is a
null pointer... indicating that converted data is to
be discarded).
If the library is built for
garbage collecting, the zone argument is
used only as a marker to say whether the function may
allocate memory (zone is non-null) or
not (zone is null).
The options argument controls some special behavior.
On return, the function result is a flag indicating
success (YES
) or failure (
NO
), and on success, the value stored
in size is the number of bytes in the
converted data. The converted data itself is
stored in the location given by dst.
NB. If the value stored in dst has
been changed, it is a pointer to allocated memory
which the caller is responsible for freeing, and the
caller is still responsible for freeing the
original buffer.
The dst argument is a pointer to a pointer to a buffer in which the converted string is to be stored. If it is a null pointer, this function discards converted data, and is used only to determine the length of the converted string. If the zone argument is non-nul, the function is free to allocate a larger buffer if necessary, and store this new buffer in the dst argument. It will *NOT* deallocate the original buffer!
The size argument is a pointer to the initial size of the destination buffer. If the function changes the buffer size, this value will be altered to the new size. This is measured in 16-bit unicode characters, not bytes.
The src argument is a pointer to the byte sequence which is to be converted to 16-bit unicode.
The slen argument is the length of the byte sequence which is to be converted to 16-bit unicode. This is measured in bytes.
The enc argument specifies the encoding type of the 8-bit byte sequence which is to be converted to 16-bit unicode.
The zone argument specifies a memory
zone in which the function may allocate a
buffer to return data in. If this is nul, the
function will fail if the originally supplied
buffer is not big enough (unless dst is a
null pointer... indicating that converted data is to
be discarded).
If the library is built for
garbage collecting, the zone argument is
used only as a marker to say whether the function may
allocate memory (zone is non-null) or
not (zone is null).
The options argument controls some special behavior.
On return, the function result is a flag indicating
success (YES
) or failure (
NO
), and on success, the value stored
in size is the number of characters in the
converted string. The converted string itself is
stored in the location given by dst.
NB. If the value stored in dst has
been changed, it is a pointer to allocated memory
which the caller is responsible for freeing, and the
caller is still responsible for freeing the
original buffer.