Re: pros and cons of returning const ref to string instead of string by value
In article <rIGdncZXwdiMe4XWnZ2dnUVZ8sKdnZ2d@bt.com>,
Francis Glassborow <francis.glassborow@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@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! ]