3 ms·
Well that's a whole other topic: does your string library support copy on write or not? If you have mostly short strings and SSO you are better off without cop
by jhallenworld 12y ago
Well that's a whole other topic: does your string library support copy on write or not? If you have mostly short strings and SSO you are better off without copy on write.
My string class has copy on write, including splicing- so it uses the most space.. I'm sure it's not really worth it (It also supports string semi-predicates: you can safely return NULL as a string and test for it- I sure wish they had this in the standard library).
struct Stringraw
{
int ref; // Reference count
int len; // String length
// String data starts here
};
class String
{
Stringraw *raw; // Pointer to possibly shared malloc block holding string
char *s; // Start of string in raw
int len; // Length of string
. . .
// Sub-string
inline String substr(int start,int size) const
{
String x;
x.s=s+start;
x.len=size;
x.raw=raw;
++raw->ref;
return x;
}
- bodyfour 12y agoJust a few days ago there was a lot of discussion here about std::string performance: https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318 I think refcounted strings are falling out of favor. In a multithreaded environment you need to use atomic ops to maintain the reference count which gets expensive. (folly's fbstring class does use them for large strings though)