Boost C++ Libraries: Ticket #3700: boost::archive should support basic_strings with different allocators https://svn.boost.org/trac10/ticket/3700 <p> Hello </p> <p> boost::archive supporting std::basic_string natively is obviously very useful. It would be even more useful if boost::archive supported std::basic_string with different allocators. It currently only supports std::basic_strings with the default allocator. If boost::archive supported std::basic_strings with different allocators, it would be very useful in writing performance code, and would be more C++ compliant. </p> <p> Thanks. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3700 Trac 1.4.3 Robert Ramey Mon, 30 Nov 2009 17:21:43 GMT status, type changed; resolution set https://svn.boost.org/trac10/ticket/3700#comment:1 https://svn.boost.org/trac10/ticket/3700#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>type</strong> <span class="trac-field-old">Bugs</span> → <span class="trac-field-new">Feature Requests</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">invalid</span> </li> </ul> <p> the string and wstring are special in that they were needed internally by the library so they were tagged a primitive. </p> <p> If you want to use your own variation, you can do it as you would for any primitive type. Derive from basic_string&lt;char&gt; (or basic_string&lt;wchar_t&gt;) and reimplement you're own special behavior. </p> <pre class="wiki">struct my_string : public basic_string&lt;char&gt; { template&lt;class Archive&gt; void serialize, ... my_string(...) : basic_string&lt;char&gt;( ... my special allocator, etc) { ... } }; ... </pre><p> If this doesn't address what you want, feel free to reopen this track item </p> <p> Robert Ramey </p> Ticket anonymous Thu, 27 May 2010 01:25:13 GMT status changed; resolution, milestone deleted https://svn.boost.org/trac10/ticket/3700#comment:2 https://svn.boost.org/trac10/ticket/3700#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">closed</span> → <span class="trac-field-new">reopened</span> </li> <li><strong>resolution</strong> <span class="trac-field-deleted">invalid</span> </li> <li><strong>milestone</strong> <span class="trac-field-deleted">Boost 1.42.0</span> </li> </ul> <p> Hi, </p> <p> The problem here is that we have our string object defined as: </p> <p> typedef std::basic_string&lt;std::string::value_type,std::string::traits_type,MyAllocator&gt; <a class="missing wiki">MyString</a>; </p> <p> boost::serialization should be able to serialize this object the same way it does a std::string. Instead it serializes it as a char array which causes very large and ugly xml. </p> <p> The reason is that in the boost serialization class it uses std::string directly. Instead all functions that are hardcoded as std::string as primitive types, they should instead be templates that use std::basic_string&lt;A,B,C&gt; so they work with any basic_string type. </p> Ticket Robert Ramey Sun, 30 May 2010 16:22:08 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/3700#comment:3 https://svn.boost.org/trac10/ticket/3700#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">reopened</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> "boost::serialization should be able to serialize this object the same way it does a std::string. Instead it serializes it as a char array which causes very large and ugly xml." </p> <p> OK you're halfway home. Now that you've got your own string type you can define the serialization anyway you want. This is not hard, but it will take a little bit of effort. You can see how it's done by checking out how it's done for std::string. </p> <p> the std:string is "special" because I use it in the archive header. Making this "special" HAS created a pain in the neck. I tried to avoid it, but at the time it seemed like it was the least worse alternatives. </p> <p> Good news is, you can define your own - as you have done - and implement any kind of scheme you wish. Carefully consider the implementation level - I would guess you want to use "object_serializable" for this. And you will have to decide how you want to represent the string in the file. Not that this last part is not trivial as you can't really know what a string is going to contain. (E.G. it can contain '\0' which so if you want some non-ugly representation, you'll have to have an escape mechanism. Good news is that the library already has tools for dealing with this - Bad news is that you have to invest effort to figure out how they have been used (data flow iterators). </p> <p> I'm sure with a little effort you can use the facilities of the library to get exactly what you want. Good Luck. </p> <p> Robert Ramey </p> Ticket