will taking the address of the first element of a string break COW strings?
in [C++]
|
Prev: will taking the address of the first element of a string break COW strings?
Next: conversion operator ambiguity
From: Brendan on 7 Jul 2010 05:13 On Jul 7, 6:27 am, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On Jul 7, 3:20 am, Brendan <catph...(a)catphive.net> wrote: > > > With vectors, you can take the address of the first element in order > > to pass the underlying data to API's that take char*'s like so: > > > vector<char> v(BUF_SIZE); > > // for some function: void write_to_buf(char* buf, size_t buf_len) > > write_to_buf(&v[0], BUF_SIZE); > > > With std::strings I've always been leery of doing the same thing since > > I know that some std::string implementations, gcc's in particular, are > > Copy On Write. > > More importantly, strings are not even guaranteed to be stored > contiguously... If strings are not guaranteed to be stored contiguously, that would certainly prevent you from taking the address of the first element to use in a similar manner to a vector. It would be nice if that were spelled this out a better, as I often want to use legacy C apis to write directly to a string to avoid an unnecessary "copy from buffer" step. Is there no change in the works for c++0x? I heard something to the effect that they were removing the possibility of COW implementation for threading performance. Was there any proposal to force the buffer to be contiguous while they were at it? Thanks for your response. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: dhruv on 10 Jul 2010 04:23 On Jul 7, 6:28 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > On 7 Jul., 04:20, Brendan <catph...(a)catphive.net> wrote: > > > With std::strings I've always been leery of doing the same thing since > > I know that some std::string implementations, gcc's in particular, are > > Copy On Write. To make this safe, a COW string str would have to make > > a copy when you do a str[index] if there is more than one reference to > > the underlying string. Does the standard require this to be safe? > > Yes. The C++03 standard does handle this problem in two ways: > > 1) It defines restrictions in regard to invalidation of pointers, > references, and iterators as follows ([lib.basic.string]/5): > > "References, pointers, and iterators referring to the elements > of a basic_string sequence may be invalidated by the following > uses of that basic_string object: > [..] > � Calling data() and c_str() member functions. > [..]" So, on a slightly tangential note, will ref-counted/COW/non-contiguous implementations _most_ likely be implemented as having a separate buffer for supporting the c_str() and data() functions? Does the standard mandate the complexity of these functions? For example say there is a string implementation that always breaks up the string into a maximum of 10 parts if it exceeds (say) 1MB. Such an implementation can guarantee O(1) lookup but not O(1) c_str() and data(). Regards, -Dhruv. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 11 Jul 2010 04:38
On Jul 10, 8:23 pm, dhruv <dhruvb...(a)gmail.com> wrote: > So, on a slightly tangential note, will ref-counted/COW/non-contiguous > implementations _most_ likely be implemented as having a separate > buffer for supporting the c_str() and data() functions? Does the > standard mandate the complexity of these functions? I think it says it must be O(1), albeit it might be 0(1) amortized. This is only a problem for non-contiguous implementations, and I don't see the link with refcounting or COW. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |