Pass by value or reference, to a C++ constructor that needs to store a copy?

Question

Should a C++ (implicit or explicit) value constructor accept its parameter(s) by value or reference-to-const, when it needs to store a copy of the argument(s) in its object either way?

Here is the shortest example I can think of:

struct foo {
    bar _b;
    foo(bar [const&] b) // pass by value or reference-to-const?
        : _b(b) { }
};

The idea here is that I want to minimize the calls to bar's copy constructor when a foo object is created, in any of the various ways in which a foo object might get created.

Please note that I do know a little bit about copy elision and (Named) Return Value Optimization, and I have read "Want Speed? Pass by Value", however I don't think the article directly addresses this use case.

Edit: I should be more specific.

Assume that I can't know the sizeof(bar), or whether or not bar is a fundamental, built-in type (bar may be a template parameter, and foo may be a class template instead of a class). Also, don't assume that foo's constructor can be inlined (or bar's, for that matter). Do assume that I at least might be using a compiler that implements RVO.

What I would like is for there to be a possibility (given compiler optimizations) that a call like this will invoke no calls to bar's copy constructor whatsoever (even when executing _b(b) in foo's initialization list):

foo f = function_that_creates_and_returns_a_bar_object_using_rvo();

Is there any possibility (given the C++98 standard) that this can be done, and if so, is it more or less likely to work if foo accepts its parameter by reference-to-const instead of by value?

Answer 1

All things being equal, I pass by const& for sufficiently complex classes, and value for POD and simple objects.

Laying out the pros/cons to pass by const reference instead of traditional pass by value

Positives:

• Avoids a copy (big plus for objects with an expensive copy)
• Read-only access

Negatives:

• Someone can const cast the const off the reference if they really wanted to

More importantly with the positives is you explicitely control when the copy happens (in your case when passing initializing _b in your initializer list). Thinking about the negatives... I agree it is a risk. I think almost all good programmers will feel dirty about emplying the const_cast. Moreover you can dutifully search for const_cast and throw tomatoes at the person casting the const off the argument. But hey you never know and who has time to watch code like a hawk :)?

My subjective opinion is that in sufficiently complex classes and in environments where the performance matters the benefit of avoiding the copy constructor outweighs the risk. However for really dumb and POD classes, I tend to make copies of the data and pass by value.

Answer 2

Look this question.

Use const T & arg if sizeof(T)>sizeof(void*) and use T arg if sizeof(T) <= sizeof(void*). All fundamental types should be the exception to this rule