Re: Why you should never use a const& parameter to initialize a const& member variable!
Daniel Kr?gler wrote:
On 3 Feb., 15:49, "Martin B." <0xCDCDC...@gmx.at> wrote:
myFAQ 0815 - Why you should never use a const& parameter to initialize a
const& member variable!
Today, once again, I shot myself in the foot. I thought I'd share this.
Rule: You must never use a const-reference parameter to a constructor to
initialize a const-reference member-variable.
Reason: const& parameters bind to temporaries. You do not want to track
temporaries!
Solution: Use a const* parameter
If you want a const& member variable in a class to reference something,
then it has to be initialized in the ctor. But you must not use a const&
parameter to the ctor to initialize the member, because this parameter
would bind to a temporary and then you would be tracking the temporary
instead of the original value.
Example demonstrating the issue:
--------------------------------
(...)
class Better {
int const& tracker_;
public:
explicit Better(int const* to_track)
: tracker_(*to_track)
{ }
(...)
While I agree that this *can* cause a problem,
I still use references to const in examples
like yours - in C++03 you have to take care here.
I say so, because there are numerous places,
where this could cause problems - just remember
a call of the std::min or std::max functions.
If the compared objects are really large one's
I don't want to copy them, therefore I may want
to get the result by reference (to const) as well.
I'm not entirely sure what you mean here. My Better object still only
uses a const& member, but the initialization is done via a pointer. So
the performance should be exactly the same?
In C++0x there is a nice way of preventing the
problem you mention: Just add an overload of the
corresponding function which accepts an rvalue
reference of the type and define the function
as deleted:
class Bad {
int const& tracker_;
public:
explicit Bad(int const&&) = delete;
explicit Bad(int const& to_track)
: tracker_(to_track)
{ }
[...]
};
I've never worked with C++0x. Am I correct in assuming that the deleted
function binds to temporaries (like fn return value or implicit
temporary from say a short or char) first and then the one that binds to
non-temporaries isn't considered anymore by the compiler?
br,
Martin
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]