0

the whole point of const_string is avoiding make a unnecesary copy when the string is not supposed to change.

However, there are circumstances where you cannot guarantee the lifetime of the const char* source to outlive the const_string, for instance, if using const_string as keys of the map, if some of the const char* become reclaimed, you'll have very amusing segmentation faults to debug ahead of you.

Is there a way to tell const_string, hey pal, please keep a private copy of this const char*? or std::string?

I'll refer to a previous question so you understand what i'm after.

Community
  • 1
  • 1
lurscher
  • 25,930
  • 29
  • 122
  • 185
  • Sounds like you are not abiding by the ownership semantics of the type you're using. – Lightness Races in Orbit Feb 26 '12 at 13:07
  • @daknøk: The second sentence in the linked text covers that (whether you agree with it or not, it's covered at least!) This looks like a `boost::shared_ptr` of sorts (well, you know what I mean) – Lightness Races in Orbit Feb 26 '12 at 13:07
  • @tomalak, maybe, but what i'm after should not be impossible; i want to keep keys in the map with their own buffers, but i want it unordered_map (or any other std/boost container) to take an instance of the same type but that doesn't need a private copy of the data (just a reference will work to do a search) because the search instance will have a well defined scope. Yeah probably i can hack something to keep the const_strings pointing to buffers hold by the map instance, but maybe i can do it less hacky? – lurscher Feb 26 '12 at 13:10
  • Why do you need to hack anything? Just don't abuse the data to which you're giving `const_string` ownership. It's just the same as _not_ writing `shared_ptr p(new T()); delete p;` – Lightness Races in Orbit Feb 26 '12 at 13:12
  • what you mean abuse the data? you mean if i feed const_string a const char* it will take ownership of it? so you mean that it will free the buffer at destruction? I think that is the part i'm not clear about and why i'm seeking clarification – lurscher Feb 26 '12 at 13:13
  • I haven't studied it in detail, but given its semantics, if it _doesn't_ free the buffer at destruction then I'd avoid it entirely. That would be very confusing. Really, despite the alleged benefits, unless copying strings has magically become a performance bottleneck for you, just pass string references around. Or `shared_ptr`? – Lightness Races in Orbit Feb 26 '12 at 13:14
  • well, take for example in LLVM, stringRef and Twine objects; stringRef holds a bare reference to a string buffer, it does not take any ownership, and if you use it and the buffer is changed you are screwd. But it is optimal for building efficient rope structures. Is not that confusing in such cases – lurscher Feb 26 '12 at 13:16
  • yes, in fact the string object is supposed to be wrapped in a boost::flyweight, but i didn't mention it in either question because i wanted to keep stuff simple. flyweight is a sort of shared_ptr for inmutable objects – lurscher Feb 26 '12 at 13:18

1 Answers1

1

And what doesn't work? By looking at the code (the documentation is mediocre at best), I can see that const_string(charp) (as opposed to const_string(boost::cref(charp)) with charp being char* should make a copy of the data. Another possibility is using the const_string(Iterator begin, Iterator end) constructor. (See the two-argument constructor of const_string_storage in storage.hpp, line 153)

They even use a temporary std::basic_string to initialize const_string in their test (I haven't run it to be honest), so it should work normally.

jpalecek
  • 47,058
  • 7
  • 102
  • 144