Re: declaring variables to be const (was retain variables between classes)
Re: declaring variables to be const (was retain variables between classes)
- Subject: Re: declaring variables to be const (was retain variables between classes)
- From: "Louis C. Sacha" <email@hidden>
- Date: Tue, 16 Dec 2003 22:06:20 -0800
Hello...
I am by no means an expert on "official" policy in regards to any
programming language, since I tend to learn languages as I go and I
haven't had much in the way of actually schooling on programming (I'm
an engineer, not a CS).
But as far as I know, const is used for specific situations and not
for general purposes.
For example, NSData returns a const void * pointer when you use the
bytes method, because you are usually getting a direct pointer to the
bytes of data it contains and if you did change any of the bytes at
that address you would in fact be changing the data contained in the
NSData object (usually a very bad thing).
In general, const is used in the Apple frameworks for buffers of
various types, when they should not be written to or as a hint that
they should be copied and not used directly.
The problem with using const for general self/idiot proofing is that
it doesn't do much good except in specific cases like those mentioned
above:
For example, if you declare your pointer to an objective-C object to
be const, it will only prevent you from changing which object the
pointer points to. You will still be able to send any message to the
object (which may or may not modify the object) but you will get a
compiler warning for every single message since the objC messaging
function in the runtime will ignore and remove the const qualifier
(and there is no way for the compiler to know if the object would be
changed by that method). And, if you are working on a pointer that
was passed in as an argument (even if at runtime you passed in an
instance variable as an argument) you can't accidentally change the
object pointed to by the pointer outside of the scope of the method
anyway, since you would be working with a copy of the pointer inside
the method.
The regular types like integers, floats, BOOLs, pointers, and all
structs are always copied when passed into a method, so any changes
within a method do not affect the original item (for example, this is
why the functions that modify an NSRect take the NSRect as an
argument and then return a NSRect, since that is the simplest way to
get the modifications outside the function). So you could require
them to be const, but it will probably not be worth it since they
only affect that limited scope....
From my perspective, the most important thing is not to arbitrarily
remove the const status of an object/value that is declared that way
(which is what that previous discussion was about if I remember
correctly). If an object/value is declared const, then it is usually
that way for a reason, and the programmer needs to honor that
declaration even though sometimes it seems like a PitA. That means
copying the object/value if you need to change it or use it
extensively, not just recasting it to the same type without the const.
If you require that most of the arguments of your methods be const,
what will happen is that you will end up recasting the objects/values
that you are passing to be const, even though they don't need to be,
which generally won't cause problems but will make using your methods
more difficult. Personally, I don't think this is a good idea, since
I think const should be reserved for situations where it is
specifically needed.
Just my $3.50...
Louis
but i've thought of another question relating to const declarations.
In Stroustrup's "The C++ programming language" he makes a bit of a
fuss about the importance of declaring arguments const if they are
not modified. This came up on the list briefly a few days ago and i
got the impression it was considered important in Obj-C also, by at
least one list member, but I haven't seen much general discussion of
it, which seems strange since many people here seem to be sticklers
for careful design of classes -- something i would like one day to
also be a stickler for.
i have plenty of methods that do not modify some/any of their
arguments - i am considering going in and changing all their
declarations to const before i go any further. I feel it may help
the compiler to help me not to screw things up. Am i right? Is there
any disadvantage to doing this?
L
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.