Are the days of passing const std string as a parameter over

Question

I heard a recent talk by Herb Sutter who suggested that the reasons to pass std  vector and std  string by const  amp  are largely gone   He suggested that writing a function such as the following is now preferable   std  string do something   std  string inval        std  string return val            do stuff        return return val      I understand that the return val will be an rvalue at the point the function returns and can therefore be returned using move semantics  which are very cheap   However  inval is still much larger than the size of a reference  which is usually implemented as a pointer    This is because a std  string has various components including a pointer into the heap and a member char   for short string optimization   So it seems to me that passing by reference is still a good idea   Can anyone explain why Herb might have said this

User · Answer

std  string is not Plain Old Data POD   and its raw size is not the most relevant thing ever  For example  if you pass in a string which is above the length of SSO and allocated on the heap  I would expect the copy constructor to not copy the SSO storage   The reason this is recommended is because inval is constructed from the argument expression  and thus is always moved or copied as appropriate- there is no performance loss  assuming that you need ownership of the argument  If you don t  a const reference could still be the better way to go

User · Answer

See    Herb Sutter  Back to the Basics  Essentials of Modern C   Style      Among other topics  he reviews the parameter passing advice that   s been given in the past  and new ideas that come in with C  11 and specifically looks at the idea of passing strings by value     The benchmarks show that passing std  strings by value  in cases where the function will copy it in anyway  can be significantly slower   This is because you are forcing it to always make a full copy  and then move into place   while the const amp  version will update the old string which may reuse the already-allocated buffer   See his slide 27   For    set    functions  option 1 is the same as it always was   Option 2 adds an overload for rvalue reference  but this gives a combinatorial explosion if there are multiple parameters   It is only for    sink    parameters where a string must be created  not have its existing value changed  that the pass-by-value trick is valid   That is  constructors in which the parameter directly initializes the member of the matching type   If you want to see how deep you can go in worrying about this  watch Nicolai Josuttis   s presentation and good luck with that     Perfect     Done     n times after finding fault with the previous version   Ever been there      This is also summarized as  F 15 in the Standard Guidelines

User · Answer

The problem is that  const  is a non-granular qualifier    What is usually meant by  const string ref  is  don t modify this string   not  don t modify the reference count     There is simply no way  in C    to say which members are  const     They either all are  or none of them are      In order to hack around this language issue  STL could allow  C    in your example to make a move-semantic copy anyway  and dutifully ignore the  const  with regard to the reference count  mutable     As long as it was well-specified  this would be fine      Since STL doesn t  I have a version of a string that const casts lt   away the reference counter  no way to retroactively make something mutable in a class hierarchy   and - lo and behold - you can freely pass cmstring s as const references  and make copies of them in deep functions  all day long  with no leaks or issues   Since C   offers no  derived class const granularity  here  writing up a good specification and making a shiny new  const movable string   cmstring  object is the best solution I ve seen

User · Answer

Herb Sutter is still on record  along with Bjarne Stroustroup  in recommending const std  string amp  as a parameter type  see https   github com isocpp CppCoreGuidelines blob master CppCoreGuidelines md Rf-in     There is a pitfall not mentioned in any of the other answers here  if you pass a string literal to a const std  string amp  parameter  it will pass a reference to a temporary string  created on-the-fly to hold the characters of the literal   If you then save that reference  it will be invalid once the temporary string is deallocated  To be safe  you must save a copy  not the reference  The problem stems from the fact that string literals are const char N  types  requiring promotion to std  string    The code below illustrates the pitfall and the workaround  along with a minor efficiency option -- overloading with a const char  method  as described at Is there a way to pass a string literal as reference in C      Note  Sutter  amp  Stroustroup advise that if you keep a copy of the string  also provide an overloaded function with a  amp  amp  parameter and std  move   it     include  lt string gt   include  lt iostream gt  class WidgetBadRef   public      WidgetBadRef const std  string amp  s    myStrRef s      copy the reference                const std  string amp  myStrRef        might be a reference to a temporary  oops       class WidgetSafeCopy   public      WidgetSafeCopy const std  string amp  s    myStrCopy s                 constructor for string references  copy the string      std  cout  lt  lt   const std  string amp  constructor n         WidgetSafeCopy const char  cs    myStrCopy cs                 constructor for string literals  and char arrays                  for minor efficiency only                 create the std  string directly from the chars      std  cout  lt  lt   const char   constructor n         const std  string myStrCopy        save a copy  not a reference      int main         WidgetBadRef w1  First string        WidgetSafeCopy w2  Second string       uses the const char  constructor  no temp string     WidgetSafeCopy w3 w2 myStrCopy         uses the String reference constructor     std  cout  lt  lt  w1 myStrRef  lt  lt    n        garbage out     std  cout  lt  lt  w2 myStrCopy  lt  lt    n       OK     std  cout  lt  lt  w3 myStrCopy  lt  lt    n       OK     OUTPUT    const char   constructor const std  string amp  constructor  Second string Second string

User · Answer

Unless you actually need a copy it s still reasonable to take const  amp   For example   bool isprint std  string const  amp s        return all of begin s  end s   bool    char  isprint       If you change this to take the string by value then you ll end up moving or copying the parameter  and there s no need for that  Not only is copy move likely more expensive  but it also introduces a new potential failure  the copy move could throw an exception  e g   allocation during copy could fail  whereas taking a reference to an existing value can t   If you do need a copy then passing and returning by value is usually  always   the best option  In fact I generally wouldn t worry about it in C  03 unless you find that extra copies actually causes a performance problem  Copy elision seems pretty reliable on modern compilers  I think people s skepticism and insistence that you have to check your table of compiler support for RVO is mostly obsolete nowadays     In short  C  11 doesn t really change anything in this regard except for people that didn t trust copy elision

User · Answer

IMO using the C   reference for std  string is a quick and short local optimization  while using passing by value could be  or not  a better global optimization    So the answer is  it depends on circumstances     If you write all the code from the outside to the inside functions  you know what the code does  you can use the reference const std  string  amp    If you write the library code or use heavily library code where strings are passed  you likely gain more in global sense by trusting std  string copy constructor behavior

User · Answer

Are the days of passing const std  string  amp  as a parameter over    No  Many people take this advice  including Dave Abrahams  beyond the domain it applies to  and simplify it to apply to all std  string parameters -- Always passing std  string by value is not a  best practice  for any and all arbitrary parameters and applications because the optimizations these talks articles focus on apply only to a restricted set of cases   If you re returning a value  mutating the parameter  or taking the value  then passing by value could save expensive copying and offer syntactical convenience   As ever  passing by const reference saves much copying when you don t need a copy   Now to the specific example      However inval is still quite a lot larger than the size of a reference  which is usually implemented as a pointer   This is because a std  string has various components including a pointer into the heap and a member char   for short string optimization  So it seems to me that passing by reference is still a good idea  Can anyone explain why Herb might have said this    If stack size is a concern  and assuming this is not inlined optimized   return val   inval   return val -- IOW  peak stack usage can be reduced by passing by value here  note  oversimplification of ABIs   Meanwhile  passing by const reference can disable the optimizations  The primary reason here is not to avoid stack growth  but to ensure the optimization can be performed where it is applicable   The days of passing by const reference aren t over -- the rules just more complicated than they once were  If performance is important  you ll be wise to consider how you pass these types  based on the details you use in your implementations

User · Answer

The reason Herb said what he said is because of cases like this   Let s say I have function A which calls function B  which calls function C  And A passes a string through B and into C  A does not know or care about C  all A knows about is B  That is  C is an implementation detail of B   Let s say that A is defined as follows   void A       B  value        If B and C take the string by const amp   then it looks something like this   void B const std  string  amp str      C str      void C const std  string  amp str        Do something with  str   Does not store it      All well and good  You re just passing pointers around  no copying  no moving  everyone s happy  C takes a const amp  because it doesn t store the string  It simply uses it   Now  I want to make one simple change  C needs to store the string somewhere   void C const std  string  amp str        Do something with  str     m str   str      Hello  copy constructor and potential memory allocation  ignore the Short String Optimization  SSO    C  11 s move semantics are supposed to make it possible to remove needless copy-constructing  right  And A passes a temporary  there s no reason why C should have to copy the data  It should just abscond with what was given to it   Except it can t  Because it takes a const amp    If I change C to take its parameter by value  that just causes B to do the copy into that parameter  I gain nothing   So if I had just passed str by value through all of the functions  relying on std  move to shuffle the data around  we wouldn t have this problem  If someone wants to hold on to it  they can  If they don t  oh well   Is it more expensive  Yes  moving into a value is more expensive than using references  Is it less expensive than the copy  Not for small strings with SSO  Is it worth doing   It depends on your use case  How much do you hate memory allocations

User · Answer

This highly depends on the compiler s implementation   However  it also depends on what you use   Lets consider next functions     bool foo1  const std  string v       return v empty      bool foo2  const std  string  amp  v       return v empty        These functions are implemented in a separate compilation unit in order to avoid inlining  Then   1  If you pass a literal to these two functions  you will not see much difference in performances  In both cases  a string object has to be created 2  If you pass another std  string object  foo2 will outperform foo1  because foo1 will do a deep copy   On my PC  using g   4 6 1  I got these results     variable by reference  1000000000 iterations -  time elapsed  2 25912 sec variable by value  1000000000 iterations -  time elapsed  27 2259 sec literal by reference  100000000 iterations -  time elapsed  9 10319 sec literal by value  100000000 iterations -  time elapsed  8 62659 sec

User · Answer

Short answer  NO  Long answer    If you won t modify the string  treat is as read-only   pass it as const ref amp   the const ref amp  obviously needs to stay within scope while the function that uses it executes  If you plan to modify it or you know it will get out of scope  threads   pass it as a value  don t copy the const ref amp  inside your function body    There was a post on cpp-next com called  Want speed  pass by value    The TL DR      Guideline  Don   t copy your function arguments  Instead  pass them by value and let the compiler do the copying    TRANSLATION of    Don   t copy your function arguments --- means  if you plan to modify the argument value by copying it to an internal variable  just use a value argument instead   So  don t do this   std  string function const std  string amp  aString       auto vString aString       vString clear        return vString      do this   std  string function std  string aString       aString clear        return aString      When you need to modify the argument value in your function body   You just need to be aware how you plan to use the argument in the function body  Read-only or NOT    and if it sticks within scope

User · Answer

I ve copy pasted the answer from this question here  and changed the names and spelling to fit this question   Here is code to measure what is being asked    include  lt iostream gt   struct string       string          string const string amp    std  cout  lt  lt   string const string amp   n        string amp  operator  const string amp    std  cout  lt  lt   string amp  operator  const string amp   n  return  this    if    has feature cxx rvalue references       string string amp  amp    std  cout  lt  lt   string string amp  amp   n        string amp  operator  string amp  amp    std  cout  lt  lt   string amp  operator  string amp  amp   n  return  this    endif       if PROCESS    1  string do something string inval           do stuff     return inval      elif PROCESS    2  string do something const string amp  inval        string return val   inval         do stuff     return return val       if    has feature cxx rvalue references    string do something string amp  amp  inval           do stuff     return std  move inval       endif   endif  string source    return string      int main         std  cout  lt  lt   do something with lvalue  n n       string x      string t   do something x    if    has feature cxx rvalue references       std  cout  lt  lt    ndo something with xvalue  n n       string u   do something std  move x     endif     std  cout  lt  lt    ndo something with prvalue  n n       string v   do something source         For me this outputs     clang   -std c  11 -stdlib libc   -DPROCESS 1 test cpp   a out do something with lvalue   string const string amp   string string amp  amp    do something with xvalue   string string amp  amp   string string amp  amp    do something with prvalue   string string amp  amp     clang   -std c  11 -stdlib libc   -DPROCESS 2 test cpp   a out do something with lvalue   string const string amp    do something with xvalue   string string amp  amp    do something with prvalue   string string amp  amp     The table below summarizes my results  using clang -std c  11   The first number is the number of copy constructions and the second number is the number of move constructions    ---- -------- -------- ---------         lvalue   xvalue   prvalue    ---- -------- -------- ---------    p1    1 1      0 2       0 1      ---- -------- -------- ---------    p2    1 0      0 1       0 1      ---- -------- -------- ---------    The pass-by-value solution requires only one overload but costs an extra move construction when passing lvalues and xvalues   This may or may not be acceptable for any given situation   Both solutions have advantages and disadvantages

User · Answer

Almost   In C  17  we have basic string view lt   gt   which brings us down to basically one narrow use case for std  string const amp  parameters   The existence of move semantics has eliminated one use case for std  string const amp  -- if you are planning on storing the parameter  taking a std  string by value is more optimal  as you can move out of the parameter   If someone called your function with a raw C  string  this means only one std  string buffer is ever allocated  as opposed to two in the std  string const amp  case   However  if you don t intend to make a copy  taking by std  string const amp  is still useful in C  14   With std  string view  so long as you aren t passing said string to an API that expects C-style   0 -terminated character buffers  you can more efficiently get std  string like functionality without risking any allocation   A raw C string can even be turned into a std  string view without any allocation or character copying   At that point  the use for std  string const amp  is when you aren t copying the data wholesale  and are going to pass it on to a C-style API that expects a null terminated buffer  and you need the higher level string functions that std  string provides   In practice  this is a rare set of requirements

User · Answer

As  JDlugosz points out in the comments  Herb gives other advice in another  later   talk  see roughly from here  https   youtu be xnqTKD8uD64 t 54m50s   His advice boils down to only using value parameters for a function f that takes so-called sink arguments  assuming you will move construct from these sink arguments   This general approach only adds the overhead of a move constructor for both lvalue and rvalue arguments compared to an optimal implementation of f tailored to lvalue and rvalue arguments respectively  To see why this is the case  suppose f takes a value parameter  where T is some copy and move constructible type   void f T x      T y std  move x        Calling f with an lvalue argument will result in a copy constructor being called to construct x  and a move constructor being called to construct y  On the other hand  calling f with an rvalue argument will cause a move constructor to be called to construct x  and another move constructor to be called to construct y   In general  the optimal implementation of f for lvalue arguments is as follows   void f const T amp  x      T y x       In this case  only one copy constructor is called to construct y  The optimal implementation of f for rvalue arguments is  again in general  as follows   void f T amp  amp  x      T y std  move x        In this case  only one move constructor is called to construct y   So a sensible compromise is to take a value parameter and have one extra move constructor call for either lvalue or rvalue arguments with respect to the optimal implementation  which is also the advice given in Herb s talk   As  JDlugosz pointed out in the comments  passing by value only makes sense for functions that will construct some object from the sink argument  When you have a function f that copies its argument  the pass-by-value approach will have more overhead than a general pass-by-const-reference approach  The pass-by-value approach for a function f that retains a copy of its parameter will have the form   void f T x      T y               y   std  move x       In this case  there is a copy construction and a move assignment for an lvalue argument  and a move construction and move assignment for an rvalue argument  The most optimal case for an lvalue argument is   void f const T amp  x      T y               y   x      This boils down to an assignment only  which is potentially much cheaper than the copy constructor plus move assignment required for the pass-by-value approach  The reason for this is that the assignment might reuse existing allocated memory in y  and therefore prevent  de allocations  whereas the copy constructor will usually allocate memory   For an rvalue argument the most optimal implementation for f that retains a copy has the form   void f T amp  amp  x      T y               y   std  move x       So  only a move assignment in this case  Passing an rvalue to the version of f that takes a const reference only costs an assignment instead of a move assignment  So relatively speaking  the version of f taking a const reference in this case as the general implementation is preferable   So in general  for the most optimal implementation  you will need to overload or do some kind of perfect forwarding as shown in the talk  The drawback is a combinatorial explosion in the number of overloads required  depending on the number of parameters for f in case you opt to overload on the value category of the argument  Perfect forwarding has the drawback that f becomes a template function  which prevents making it virtual  and results in significantly more complex code if you want to get it 100  right  see the talk for the gory details

[c++] Are the days of passing const std::string & as a parameter over?

Examples related to c++

Examples related to c++11