c++ - Move semantics and virtual methods -

in c++11 guided in cases pass objects value , in others const-reference. however, guideline depends on implementation of method, not on interface , intended usage clients.

when write interface, not know how implemented. there rule of thumb writing method signatures? example - in following code fragment, should use bar1 or bar2?

class ifoo { public:     virtual void bar1(std::string s) = 0;     virtual void bar2(const std::string& s) = 0; }; 

you can stop reading here if agree correct signature depends on implementation. here example shows why believe so.

in following example, should pass string value:

class foo {     std::string bar;      foo(std::string byvalue)         : bar(std::move(byvalue))     {     } }; 

now can instantiate foo in efficient manner in cases:

foo foo1("hello world"); // create once, move once foo foo2(s); // programmer wants copy s. 1 copy , 1 move foo foo3(std::move(t)); // programmer not need t anymore. no copy @ 

in other cases prefer pass objects const reference. example, in following case never want copy/store argument, use methods:

void dostuff(const std::string& byref) {     std::cout << byref.length() << std::endl; } 

all possible usages of above method efficient possible.

update

i believe forgot show issues const-reference alternative. if above class foo implemented way:

class foo {     std::string bar;      foo(const std::string& byref)         : bar(byref)     {     } }; 

then have following results:

foo foo1("hello world"); // here have 1 more copy of string. less efficient. foo foo2(s);             // 1 copy, before foo foo3(std::move(t));  // irrelevant here. 

alex.

there's no "theory of everything" here. got right, there's problem. remember confronting myself while back.

my conclusions started here:

application vs. framework/library development

if clients developers, job harder. not harder, there no clear guidelines. great framework designers got prestige because happened take risks paid off. @ same time, in alternate universe, risks have not paid off. that's because appreciating framework depends on direction of growing usage, , subjective opinions harder reason in application domain.

so there's no clear cut answer in case. fortunately, think you're interested in application development here. let's on that.

starting point: we're developing applications

this makes huge difference. because we're supposed have better idea of system going, , kind of code turn out useful. we're not prophets, @ same time assumption allows give more credit our intuition, based on our knowledge of requirements, , needs of our customers (at least as able understand).

at point, can still divide 2 cases:

abstraction implementation

there cases beneficial, or necessary, define abstraction ahead of implementation. in cases this, 1 has realize more research problem required before defining abstraction properly. example, domain synchronous or asynchronous? serial or parallel? high or low level? , other more concrete questions.

some extreme agilers have believe can write code , fix later. however, claim falsified once reality hits. if find hope in it, encourage test , report if made significant discovery. personal experience, , thought have tried putting matter, suggest in big projects approach problematic.

the conclusion in case that, if indeed need define abstraction ahead, should have idea of implementation. better idea have it, higher chance succeed in being proper abstraction.

implementation abstraction

this default choice. has been said in many ways. "frameworks should extracted", "extract 'till drop", , "convention on configuration" has similarities in concept.

basically means implement required components necessary, keep sharp eye on what's going on. trick here out chances abstract in ways benefit practically in terms of development , maintenance.

this comes class want, more. in case, abstract intersection away more general case. repeat process necessary throughout development.

it's important not caught , still keep feet on ground. i've seen many abstraction attempts go wrong point there's no way reason name , deduce intent except reading thousands of lines of code use it. example, in current code base i'm working on, type should have been called image called binarydata. across code attempts treat concrete (image), , abstract concept @ same time.

to sum up

as remind myself, best best practice can have tame known best practices fit problem, rather other way around. if can't that, well, maybe problem interesting enough require further attention, , bit of original thought.