Dean Michael Berris wrote:
On Fri, Mar 18, 2011 at 6:37 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 18/03/2011 03:49, Dean Michael Berris wrote:
That's fine, I deal with lots of network I/O as part of the HTTP implementation in cpp-netlib and it would be really good if I can step away from std::string from the internals to support larger strings without having to induce too much fragmentation when concatenating strings. The intention is to have suitably efficient (not necessarily optimal) string representations for code that need to deal with both small and potentially huge strings.
Then you need a string which layout is compatible with the vectored I/O API provided by the system (readv/writev on POSIX, ReadFileScatter/WriteFileGather on Win32).
Thanks Mathias, yes the data storage structure I'm looking to use will mostly obtained with either by mmap'ing an anonymous segment or through posix_malign(...) -- not sure of the Windows equivalent. The storage blocks would basically be chunks in memory, and I'm looking to make a chain a Boost.Asio compatible ConstBufferSequence.
Hi, I would like to see the requirements for ConstBufferSequence be relaxed. In particular X::value_type --- T --- T meets the requirements for ConvertibleToConstBuffer. I would like it uses a model of ConstBuffer and Mutable Buffer instead of forcing a conversion to the specific class cont_buffer. The ContBuffer, Mutable requirements could be resumed to the ability to get the size and the (const/mutable) address either as member functions or as free functions. This relaxation on the requirements will avoid unneeded conversions. It seems to me that the user code will not inpact :). However the ASIO code will need to be changed in some places :( Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Chain-over-at-Github-tp3384959p3389... Sent from the Boost - Dev mailing list archive at Nabble.com.