Re: Objective-C++, class scope constants, name conflicts
Re: Objective-C++, class scope constants, name conflicts
- Subject: Re: Objective-C++, class scope constants, name conflicts
- From: Erik Buck <email@hidden>
- Date: Thu, 9 Feb 2006 23:26:47 -0500
I am confused.
In C99,
static const int controlSetCnt = 0; declares storage for an integer.
If you put the declaration anywhere in an Objective-C header, I think
EVERY compilation unit that #imports the header will end up with its
own separate storage for an integer. If two or more headers declare
the same symbol and are #imported into the same compilation unit,
there will be a duplicate declaration error at compile time.
The traditional and well tested C technique for defining a symbolic
constant is to use the C preprocessor #define directive as follows:
#define BloodPressureControlSetCount (0)
You will find many defined constants in Cocoa.
I am confused, why would you want to write the following:
BloodPressure_ControlGroup * bpControls[controlSetCnt];
Assuming BloodPressure_ControlGroup is an Objective-C class, you
probably want to use NSArray to store an array of instances. The
NSArray will manage reference counts, enable the use on NSEnumerator,
and keep your class flexible. I would argue that if any other class
needs to know how many BloodPressure_ControlGroup are stored at
instantiation time is a gross violation of encapsulation.
If BloodPressure_ControlGroup is some kind of I/O device data
structure and isn't a class at all, you may want to create a fixed
size C array. However, I think exposing this detail in an Objective-
C class interface is a huge violation of encapsulation.
Consider the following:
@interface SomeClass : NSObject
{
BloodPressure_ControlGroup **bpControls;
}
- (int)numberOfBloodPressureControls;
- (const BloodPressure_ControlGroup **)bpControls;
@end
Not knowing your exact problem, I am not convinced that the number of
BloodPressure_ControlGroup elements (instances or structures or
whatever) is relevant code that instantiates instances of a class.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden