RE: [boost] immutable string
Maxim Yegorushkin <e-maxim@yandex.ru> wrote:
I've been working on a small library - an immutable C++ string. Now it is in usable state and has been put in use in a couple of real projects. Although it needs further polishing, I would like to know is there any interest in such a library?
Great stuff. I certainly think it would be useful to have a light- weight string.
Here is the link: http://conststring.sourceforge.net/
There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC? [*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about. Ben.
Ben Hutchings <ben.hutchings@businesswebsoftware.com> wrote: []
There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC?
[*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about.
No, it's not safe now. I'll fix it. But I wonder, why would anyone want to instantiate a string type with double? How is it better than a std::vector<double>, which seems to be a natural choice? -- Maxim Yegorushkin
From: "Maxim Yegorushkin" <e-maxim@yandex.ru>
Ben Hutchings <ben.hutchings@businesswebsoftware.com> wrote:
There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC?
[*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about.
No, it's not safe now. I'll fix it.
But I wonder, why would anyone want to instantiate a string type with double? How is it better than a std::vector<double>, which seems to be a natural choice?
He wasn't suggesting that anyone would. He was suggesting that you don't know the alignment requirements of char_t, so one way to test your alignment assumptions is to use double. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote: []
He wasn't suggesting that anyone would. He was suggesting that you don't know the alignment requirements of char_t, so one way to test your alignment assumptions is to use double.
Ok, I see now. -- Maxim Yegorushkin
Ben Hutchings <ben.hutchings@businesswebsoftware.com> wrote: []
There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC?
[*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about.
I fixed it using the union trick. But I think there might be another solution. The standard states in 5.3.4.10 that arrays of char's allocated with new expression are always properly aligned for types whose size is no greater than the size of the array. Does allocator<char>::allocate() have the same requirement? I could not find it in my copy of the standard. -- Maxim Yegorushkin
participants (3)
-
Ben Hutchings -
Maxim Yegorushkin -
Rob Stewart