I'm confused by this statement. Take that simple C++ String class
again. If you have:
String a = "aaa";
String b = a;
String c = a;
...don't a, b, and c all own the underlying char buffer? (And yes,
a char buffer isn't an object, but that's what the article you
linked to is referring to when it mentions ownership.)
Well, I presume you mean the "underlying buffer" is the copy that
'a' creates from the "aaa" string in its constructor? Because, as
you're aware, but a beginner following this thread might not, constant
strings are owned by the runtime and do not have to be malloced or
freed (Same goes for constant ObjC strings, though there you can
retain and release them, so you don't have to write separate code for
constants and dynamically allocated strings, but it doesn't have any
effect on the constant ones, really).
The implementation the article mentioned in your link (http://www.linuxdevcenter.com/pub/a/linux/2003/05/08/cpp_mm-1.html?page=2
) actually provides, shows that SimpleString makes a copy of the
string. So 'a' owns its copy of the "aaa" string. The constant is
owned by the compiler, and due to a programming bug (the missing copy
constructor) all three SimpleStrings think they own the same buffer.
To keep this on-topic, you could achieve the same problem by
forgetting to implement a -copy method on an object whose base class
is declared to adhere to the NSCopying protocol. Similar results can
also be obtained by forgetting to provide an -initWithCoder: in a
subclass of a class that is intended to be instantiated from a coder.
If you want a fun description of problems like these, look up James
Dempsey's "Designated Initializer" song on YouTube.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
