From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-01-31 12:30:21
>> 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