RE: object-model: Return by value, reference or pointer? (or something else?)
From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 14 Oct 2010 13:24:33 +0100
-----Original Message-----
> Do you need the distrinction between an empty string and a NULL?
> There's also the consideration that some std::string implementations
-- Yes, it does, they removed refcounts after VC6. The problem with refcounting a std::string is the performance of it in a threaded environment is worse than simply copying the string (you have to handle all the copy-on-write issues and this gets difficult). http://www.sgi.com/tech/stl/string_discussion.html describes some of the problems. I have agree with Steiner - what's the difference between a null string and an empty string? Typically there is no difference. In the case of C there was, as the char* might be NULL, or it might point to a byte with \0 as its first character. That NULLness is an artefact of how C manages string memory, not any way of describing the string. Once you start using both, you get stuff like .NETs '.IsNullorEmpty()' methods - and then you're back right where you started, treating a NULL and an empty string as the same thing. In C++, if you really need to return either nothing or a string, return a std::pair<bool, std::string> (like std::map uses to indicate if the insertion succeeded or failed due to an existing key was already present in the map). Most DB access methods return the datatype, and another indicator whether the data was NULL. Personally, I would stick to just returning a string, or if it is essential to return a null value, return a string and an null indicator - your choice whether that's best as a pair, or an out parameter. I would not inherit from std::string, nor would I throw an exception (not that anyone's yet suggested that - we're not C# or Java programmers after all :-) ) AndyReceived on 2010-10-14 14:25:26 CEST |
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.