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.

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.

To be used inside a method for making sure that a range does not specify anything outside the size of an array/string. Raises exception if range extends beyond [0,size]. Size must be an unsigned integer (NSUInteger).
Checks whether INDEX is strictly less than OVER (within C array space). INDEX and OVER must be unsigned integers (NSUInteger).

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.

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.

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 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.

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.

To be used inside a method for making sure that a range does not specify anything outside the size of an array/string. Raises exception if range extends beyond [0,size]. Size must be an unsigned integer (NSUInteger).

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 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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.

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 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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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).

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).

A constant which is the lowest possible version number (0) so that when used as the removal version (second argument of the GS_API_VERSION or OS_API_VERSION macro) represents a feature which is not present in any version.
eg.
#if OS_API_VERSION (GS_API_NONE, GS_API_NONE)
denotes code not present in OpenStep/OPENSTEP/MacOS-X
A constant to represent a feature which is still present in the latest version. This is the highest possible version number.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.
The version number of the initial OpenStep specification.
eg.
#if OS_API_VERSION (GS_API_OSSPEC, GS_API_LATEST)
denotes code present from the OpenStep specification onwards.
The version number of the first OPENSTEP implementation.
eg.
#if OS_API_VERSION (GS_API_OPENSTEP, GS_API_LATEST)
denotes code present from the initial OPENSTEP version onwards.
The version number of the first MacOS-X implementation.
eg.
#if OS_API_VERSION (GS_API_MACOSX, GS_API_LATEST)
denotes code present from the initial MacOS-X version onwards.

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.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is like NSWarnLog() but includes the name and location of the method in which the macro is used as part of the log output.
The DLog macro is a less powerful but commonly used logging macro, defined here for convenience when porting code. It will tell you the function name and line number but not the file location. It performs unconditional logging but is only compiled in when the program is built with DEBUG defined.
The Alog macro is the same as the DLog macro, but is always compiled in to the code whether DEBUG is defined or not.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is like NSWarnLog() but includes the name and location of the method in which the macro is used as part of the log output.
The DLog macro is a less powerful but commonly used logging macro, defined here for convenience when porting code. It will tell you the function name and line number but not the file location. It performs unconditional logging but is only compiled in when the program is built with DEBUG defined.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is like NSWarnLog() but includes the name and location of the method in which the macro is used as part of the log output.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is like NSWarnLog() but includes the name and location of the method in which the macro is used as part of the log output.

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 key 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 keys 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 keys from the array given by the GNU-Debug default... 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 key 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 keys under your programs control - NSProcessInfo has a [-debugSet] method that returns the mutable set that contains the active debug keys - your program can modify this set.

Two debug keys have a special effect - 'dflt' is the key used for debug logs statements where no debug key 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.

This macro is a shorthand for NSDebugLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugFLLog() using the default debug key... 'dflt'
This macro is like NSDebugLLog() but includes the name and location of the method in which the macro is used as part of the log output.
This macro is a shorthand for NSDebugMLLog() using then default debug key... 'dflt'
This macro saves the name and location of the function in which the macro is used, along with a short string msg as the tag associated with a recorded object.
This macro saves the name and location of the method in which the macro is used, along with a short string msg as the tag associated with a recorded object.
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a function. Pass an NSString as a format, followed by zero or more arguments for the format string. Example: GSOnceFLog(@"This function is deprecated, use another");
Macro to log a message only the first time it is encountered.
Not entirely thread safe... but that's not really important, it just means that it's possible for the message to be logged more than once if two threads call it simultaneously when it has not already been called.
Use this from inside a method. Pass an NSString as a format followed by zero or more arguments for the format string.
Example: GSOnceMLog(@"This method is deprecated, use another");

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.

This macro is like NSWarnLog() but includes the name and location of the function in which the macro is used as part of the log output.
This macro is like NSWarnLog() but includes the name and location of the method in which the macro is used as part of the log output.

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.

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.

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() .

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.

• If GSUniStrict is set, the function will fail if a character is encountered in the source which can't be converted. Otherwise, some approximation or marker will be placed in the destination.
• If GSUniTerminate is set, the function is expected to nul terminate the output data, and will assume that it is safe to place the nul just beyond the end of the stated buffer size. Also, if the function grows the buffer, it will allow for an extra termination byte.
• If GSUniTemporary is set, the function will return the results in an autoreleased buffer rather than in a buffer that the caller must release.
• If GSUniBOM is set, the function will read the first unicode character as a byte order marker.
• If GSUniShortOk is set, the function will return a buffer containing any decoded characters even if the whole conversion fails.

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.

• If GSUniTerminate is set, the function is expected to null terminate the output string, and will assume that it is safe to place the nul just beyond the end of the stated buffer size. Also, if the function grows the buffer, it will allow for an extra termination character.
• If GSUniTemporary is set, the function will return the results in an autoreleased buffer rather than in a buffer that the caller must release.
• If GSUniBOM is set, the function will write the first unicode character as a byte order marker.
• If GSUniShortOk is set, the function will return a buffer containing any decoded characters even if the whole conversion fails.

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.