Re: 'academic' problem ( speed/memory efficiency vs. human readability and

Dave Harris wrote:


and it's not just virtual functions. Think about that most basic class,
the string. Now let's suppose we are going to implement std::string
(for this purpose let's just call the class string and ignore the fact
that it's a template or char_traits etc).

string & string::operator=( const string & rhs )

or

string & string::operator=( string rhs )

Are we going to make a copy? It depends. If our current buffer is big
enough to hold the target string we are not going to do a reallocation
at all. We will simply copy the string we receive into our buffer and
change our logical size.

If our current buffer is not big enough then we will use the copy &
swap technique (to ensure strong exception safety).

Now of course we know that string has an implicit conversion from const
char *. So what do we do if we are:

A: passed in a reference to a genuine string object that has size <=
our string
B: passed in a reference to a genuine string object that has size > our
string
C: passed in a const char * that has size <= our string
D: passed in a const char * that has size > our string.
E. passed in a temporary that has size <= our string
F. passed in a temporary that has size > our string.

I will assume that the overheads are making an allocation and copying
the buffer and that creating a blank string object is relatively cheap.

In the optimal solution A requires 0 allocations and 1 buffer copy, all
of the others require 1 allocation and 1 buffer copy.

If we take our parameter by const reference we avoid the unnecessary
allocation in case A but make an extra allocation and an extra buffer
copy in cases D and F.

If we take our parameter by value we lose out only in case A where we
make an extra allocation but we don't make any extra buffer copies.

If the strings are long, we might assume that the buffer copy is the
more expensive action, but if they are short the allocation probably
is.

Is there a way to get the best of both worlds? Well yes there is with
regards to the implicit conversion (case D) but it requires extending
our interface. If we also provide operator=( const char * ) we will
never get the implicit conversion in the assignment and we will be able
to optimise both functions appropriately, never allocating or copying
more often than is necessary.

Are we "exposing the implementation to the user"? No, not really. (As
string in reality is a template of course we do anyway but ignore that
fact). We do allow assignments to const char * buffers as well as to
const string &. The user would not be using the class any differently.

How about the temporary? (I am assuming by the way that we have RVO so
between the return value from the function and the parameter there is
no construction, even in a "pass by value" situation). Well this would
require the compiler to use even more skilled RVO to enable us to
"transfer ownership". (Something I suggested in my other post). If it
has already worked out that we do in fact "own" this string (even
though our reference is const) it should optimise away the copy
constructor.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]