|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk