Second use for me is to have a basic_string compatible buffer to use in shared memory/IPC.
struct commandlineargs { boost::fixed_string<20> arg1; boost::filesystem::basic_path<boost::fixed_string<256> > path1 };
Isn't that what the allocator argument to basic_string is for?
I agree with Dave, I don't see the need of a fixed string for IPC: a fixed_buffer_allocator for basic_string should do the job. You have two possibilities: -> Use an allocator that has the buffer as member. The only drawback is that the string will create a temporary default constructed allocator and will assign it to the basic_string's member allocator. So you have a extra stack when constructing the basic_string. And the allocators have private, per-instance memory, and can't be swapped (like current Howard Hinnant's proposal says), so they are stateful allocators (which I think are not standard). -> Use an allocator that holds the pointer and size of a buffer. This is more flexible but you can't freely pass the string because the lifetime of the buffer must be the same as the lifetime of the basic_string. But sometimes this could be very useful and you can swap the strings. char buffer [100]; c_buffer_allocator a (buffer, 100); basic_string<char, std::char_traits<char>, a> str (a); In both cases when trying to reallocate memory, the allocator would throw an exception, so we have buffer protection, and all basic_string uses. -> Another alternative to work with fixed buffers is to create a buffer formatting iostream. For example, in Boost candidate Shmem you have bufferstream classes: basic_bufferstream<char, std::char_traits<char> > bufstream; bufferstream mybufstream(my_cstring, 100*5); bufstream << int(1) << "text" << std::ends; If you read past-end the buffer, that will trigger eofbit and if you try to right past-end you will have badbit activated. You can activate also exceptions, like with other iostreams. Regards, Ion