pros and cons of returning const ref to string instead of string by value
in [C++]
|
Prev: Why no placement delete?
Next: pros and cons of returning const ref to string instead of string by value
From: Andy Venikov on 3 Dec 2009 07:53 restor wrote: >> Frankly, what you describe seems like a perfect fit for using shared_ptr >> >> Have your member be a shared_ptr<std::string>. >> And return shared_ptr<const std::string> from your getter function. > > shared_ptr adds itself a visible overhead, and may even be slower than > returning string by value if the string has an embedded reference > counting. > > Regards, > &rzej > That's true, but it's all very implementation depended - not all std::strings are equal and some might not implement reference counting. shared_ptr on the other hand is always reference-counted. Having said that, I just remembered an item from Scott Myers' "effective STL" where he described a std::string implementation from four leading libraries (which ones he did not mention) and I believe all of them were reference counted. Andy. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 3 Dec 2009 23:00 Nevin :-] Liber wrote: > In article <6LednaHXT5qNForWnZ2dnUVZ8mWdnZ2d(a)bt.com>, > Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: > >> Note that we also need to consider whether the caller may want only the >> current value or to be able to track the value. That leads to me >> wondering whether we should not sometimes return a const volatile reference. > > Could you elaborate on why one would need volatile? > > As you well know, all that const reference means is that the intention > is not to modify the object through this alias (mutable, const_cast, > etc. notwithstanding, of course). > But if we hold a const reference the compiler believes that the underlying object will not change. By flagging it as volatile as well we warn the compiler that the underlying object may change out of our sight. Of course in the case of single threaded code the compiler will assume that a const reference might change if a function is called that has independent access to the object but in the case of multi-threaded code the compiler (for a single TU) has no reason to expect that the object might be modified (in a different thread) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nevin :-] Liber on 4 Dec 2009 01:51 In article <rIGdncZXwdiMe4XWnZ2dnUVZ8sKdnZ2d(a)bt.com>, Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: > But if we hold a const reference the compiler believes that the > underlying object will not change. By flagging it as volatile as well we > warn the compiler that the underlying object may change out of our > sight. Of course in the case of single threaded code the compiler will > assume that a const reference might change if a function is called that > has independent access to the object but in the case of multi-threaded > code the compiler (for a single TU) has no reason to expect that the > object might be modified (in a different thread) Volatile does not solve the multithreaded issue; you have to synchronize access to the object. Are there any compilers out there which incorrectly make assumptions about their own synchronization primitives such that they assume the underlying object hasn't changed across a synchronization boundary? And const volatile references make things a whole lot messier. Since copy constructors take their parameter by const non-volatile reference, the following code won't compile: std::string s("Hello, world!"); std::string const volatile & scvr(s); std::string copys(scvr); // error -- Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Stuart Golodetz on 4 Dec 2009 11:14
Nick Hounsome wrote: > On 3 Dec, 17:21, Stuart Golodetz > <sgolod...(a)NdOiSaPlA.pMiPpLeExA.ScEom> wrote: > >> int main() >> { >> shared_ptr<X> x(new X); > > The following line is NEVER a good idea. > I know a lot of people seem to think that a class should be written to > be idiot proof but idiots are so inventive that that is difficult - I > prefer to just not employ idiots. > >> const std::string& r = x->s(); Ok, I'll bite and risk looking like an idiot :) Why do you think it's *never* a good idea? As to class design - I agree with you (up to a point). A true idiot will find a way to break anything :) I'd still program defensively to guard against the most likely client mistakes, though. Stu >> x.reset(); >> >> // BOOM >> std::cout << r << '\n'; >> >> return 0; >> >> } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |