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: Scott Ribe <email@hidden>
- Date: Fri, 10 Feb 2006 12:23:56 -0700
- Thread-topic: Objective-C++, class scope constants, name conflicts
> I am confused.
Yeah, I think you've misread the question and made it way more complicated.
I just want a proper class-scoped constant--only visible within the class
and not susceptible to name clashes with constants in other classes.
> 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.
And in C++, if you put it inside the class declaration, it is a class member
and is not visible outside the class and there is storage for at most 1
integer, although likely there will be no integer at all.
> 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)
And this does nothing to avoid the name clash when 2 different windows need
to define a (possibly different) count of blood pressure control sets.
> 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.
I have no need at all for an NSArray. BloodPressure_ControlGroup is indeed
an Objective-C class, instantiated 6 times in the nib, hooked up
appropriately, retained by the window controller. All I want is a simple
array that I can iterate over rather than writing highly redundant code to,
for instance, check each group of controls for valid data.
> 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.
Nope, they are controls in the UI widget sense. There's 6 groups on the
window, and only the window needs to know this detail. And I have no
intention of exposing the number via the class interface; the constant
should be private to the class--sort of the point of my request, and exactly
the problem with #define...
> 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.
Well, it is, because the window controller needs to manage that many groups
of widgets. The window controller does not automatically adjust to different
numbers at runtime because there is no need to do this, the number is fixed.
And yes, I could just as easily use std::vector< BloodPressure_ControlGroup
* >, but why?
Given the other off-target responses I've gotten, (and that I checked
documentation before posting) I'm just going to assume that in Objective-C
there is no notion of a constant with class scope. Seems an odd omission,
but if that's the way it is, then that's the way it is ;-)
--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 722-0567 voice
_______________________________________________
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