Re: Legacy APIs which output C-style strings: Opportunity to use move semantics?
null hypothesis wrote:
On Aug 8, 3:57 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
[...]
a) Memory governed by a string is handled via an allocator. If you move
from a char* the information about how the memory for the char* was
allocated (and has to be deallocated) is lost.
Assume we move a char * to a mystr S allocated with allocator A: Is it
too
difficult for the compiler to:
*) free the original contents of S by calling A.destroy()
*) know full well that it is moving a char * with some (probably
magic) allocator
and mark it as such?
No, that might not be too difficult. But it does not solve the problem.
How should the destructor of the string go about releasing the memory? After
all, even if the compiler passes the information that the memory was
allocated via weird_alloc_method_from_library_X to the string, how could it
guess successfully the required deallocation function?
b) String implementations have to manage size information (e.g., because
strings are allowed to contain 0-characaters). It is not ruled out that
the size information is put into the same contiguous memory as the
character sequence, which then has to be sizeof(size_type) longer.
And the reverse is equally true -- the implementation can choose to
keep this as a
separate member of the basic_string_impl struct. Then all we need is
swap the
data member of this struct and initialize the length = capacity to
equal the
length of the string.
True, but mandating move constructors in the standard would essentially
force this implementation. I can see why the committee decided not to go
that way.
In moving from
char* to string, it might be impossible to obtain this additional piece
of memory in the right place.
When moving from char * to strings, why would I even consider anything
beyond
the first null terminator?
The problem is not the space beyond the first null terminator but the space
_before_ the character sequence. That is a place where the string
implementation (in the memory it manages via the allocator) may store the
size information. With a char* provided from the outside, that space might
not be available.
Moving the other way, you run into problems when
it comes to deallocating the char*.
Yes, absolutely. I should have stated this, but I did not intend that
basic_strings
could be moved to a char *. Such semantics would be as limited as
c_str() is.
So, I am looking at something like:
/*
** The function replaces the string controlled by *this
** with a string of length strlen(str) whose elements
** are a copy of the string controlled by str. Leaves str
** in a valid but unspecified state.
*/
basic_string<charT,traits,Allocator>&
assign(_Elem *str);
Or, more generally:
struct mystr {
size_t len;
char *b;
mystr() : len(0), b(0) {}
mystr(mystr const& s)
: len(s.len),
b(new char[len + 1]) {
memcpy(&b[ 0 ], &s.b[ 0 ], len + 1);
}
mystr(mystr&& s)
: len(0), b(0)
{
swap(b, s.b);
s.len = 0;
}
mystr(char *s)
: len(strlen(s)), b(0) {
swap(b, s);
}
/**
Others omitted for brevity
*/
};
Note that this implementation does not take care of the allocator issue
by implicitly assuming the char* member and the free char* are to be
deallcated the same way.
Not that this did not occur to me, but I was trying to explain
what I was trying to devise: A one way char * to string move semantics
for the
string library. I intentionally left the allocator out for simplicity.
Even without the allocator, the rub comes with the destructor.
BTW: Why doesn't basic_string have a ctor analogous to
vector(size_type n)?
It does:
basic_string(size_type n,
charT c,
const Allocator& a = Allocator());
The difference is only that you may not omit the charT parameter c.
Best
Kai-Uwe Bux