* Old Wolf:
How about:
void foo(SomeClass const &);
int main()
{
SomeClass a;
SomeClass b(a);
foo(b);
}
Can that copy-constructor and side-effect be elided because
the compiler determines that 'a' is never used again, and
it decides to simply use 'b' and 'a' to both refer to the same
bit of memory?
I could just give an answer, pretending to absolutely know such details, but
I think it's more honest to explain the process towards that answer.
1. I read your question and I'm _fairly sure_ the answer is yes, because of
what's commonly called the "as if" rule, and I'm planning to mention the
rather non-obvious requirement for a copy constructor, generated or
user-defined, when passing by ref to const (discovered during AA's Mojo
adventure), and also the difference when a and b's adresses might be used.
2. I plan to check the 1998 standard. But first, I make some coffee.
3. I discover that I'm almost out of coffee, and I've just been down to 7-11
and not very keen to make another trip, it takes twelve minutes each way.
What's needed to cancel the spiritual effects of this severe psychological
setback is evidently a bite of "Gullbrød" chocolate, favoured by our Prime
Minister. "Gullbrød", wolfed down (hah), one more cup of coffee, down.
4. Acrobat Reader informs me there's an update available. And not just one!
However, no matter what is selected it insists on also installing Yahoo
Toolbar. F**k off, Adobe. I don't want no sneaking malware Yahoo Toolbar,
_especially not_ one that cannot be deselected in the installation dialog.
5. OK, the "as if" rule, that's §1.9/1, "confirming implementations are
required to emulate (only) the observable behavior of the abstract machine
as explained below", where the key word is _observable_. §1.9/6 then
defines observable behavior as the "sequence of reads and writes to volatile
data and calls to library I/O functions", with a note explaining that
library I/O functions include such functions added by the implementation.
So already, given that copy constructors can be elided without regard to
their side-effects, this provides the answer "yes" to your question. But I
gather you're interested also in the copy constructor side-effect issue.
6. The possibility of ignoring side-effects in copy constructors is
mentioned twice in e.g. §12.8/15, about eliding temporaries for
initialization and function results, "even if the copy constructor or
destructor have side effects". So there I learned something new. Even
though it was implicit in what I already knew I hadn't really thought about
a destructor with side-effects, but there you are: neither copy constructor
nor destructor side-effects can be relied on in C++. It's all Andrei
Alexandrescu's fault, because as I recall he wrote in MC++D that the copy
constructor was special in this regard. But it's also destructors.
7. Regarding the requirement for a copy constructor to exist for passing by
reference to const, well, I don't find it. But I'm fairly sure it's there,
somewhere, even for C++2003. And also that it will be fixed in C++0x.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?