Re: strange compiler message
From: Tobias Güntner (fatbull_at_users.sourceforge.net)
Date: 08/02/04
- Next message: Gianni Mariani: "Re: portability issues"
- Previous message: grzecho: "read - website CODE"
- In reply to: Neil Zanella: "Re: strange compiler message"
- Next in thread: Neil Zanella: "Re: strange compiler message"
- Reply: Neil Zanella: "Re: strange compiler message"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 02 Aug 2004 00:08:25 +0200
Neil Zanella wrote:
> Tobias Güntner <fatbull@users.sourceforge.net> wrote in message
>
>
>> The same problem occurs in this case: foo modifies a temporary int
>> - not myfoo, as the user expects.
>
>
> How could this be the problem? It's obvious from the signature of
> method foo(int &) that myfoo will not be modified because it is not
> an int but an object of class Foo. How could this possibly confuse
> anyone?
Because the user/programmer does not see the functions signature at
first sight or the programmer has to make a few
last-minute-bugfixes and has no time to check the signatures. Or maybe
the programmer is just sloppy. One never knows ;)
Here's another example (there was a link to it in this thread):
void trim_whitespace(string& str);
int main()
{
trim_whitespace(" blah blah ");
return 0;
}
Now show me someone who would not be confused because the string literal
won't be modified. Or what if a user defined class provided a conversion
to string? trim_whitespace would not modify the object that has been
passed as parameter (at least from the user's point of view - the
compiler of course knows about any implicit conversions)
The point is: Because implicit conversions are performed, you might
*involuntaryly* pass a temporary object to a function that is supposed
to modify the original object.
If you're still in doubt, maybe this
<http://www.cuj.com/documents/s=7976/cujcexp2012hyslop/> will convince you.
> There must be a better reason why the standard disallows passing a
> temporary to a function that takes a non-const reference.
> What I find really strange is that since the object passed to such a
> function is a temporary, I can't see that anyone would care about
> whether it gets modified or not:
Usually you pass objects to a modifying function because you really want
it to modify an object, don't you?
> since the object is temporary, the programmer will never have a
> chance of accessing it ever again
Exactly! Now tell me: Why should I call that function if I never use its
results? (and I'm not talking about error return codes here)
Why call a function that has absolutely no side effects? (or more
exactly: whose side effects vanish immediately after the function has
returned?)
> so why would the programmer care, and why would the standard disallow
> it, given that it makes no difference whether the temporary is
> modified or not: after all, it's just a temporary.
Because in 99 out of 100 cases you don't want to modify a temporary. In
most cases you care for the result, otherwise you wouldn't call that
function.
> class X { public: X(): x(0) {} void modify() { x = 1; } private: int
> x; };
<snip>
> int main() { X().modify();
That's OK (i.e. this is the remaining 1 out of 100 cases), because you
consciously & deliberately created a temporary object here - no danger
of subtle bugs in this case.
-- Regards, Tobias
- Next message: Gianni Mariani: "Re: portability issues"
- Previous message: grzecho: "read - website CODE"
- In reply to: Neil Zanella: "Re: strange compiler message"
- Next in thread: Neil Zanella: "Re: strange compiler message"
- Reply: Neil Zanella: "Re: strange compiler message"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
