bytes to start from; the accumulator enlarges itself
whenever the message outgrows it, so this only trades an initial allocation
against the number of enlargements and never limits the message. A caller with
a rough size in hand should pass it: 100 KB of small fields grows by doubling
and costs nine enlargements from the 256-byte default. A single large field
does not โ a bulk write hands the sink its needed, so the buffer reaches that
size in one step and the write keeps its bulk route.
An OStream whose buffer follows the message โ the ready-made form of the caller CORELIB_PLAN ยง5.1.2 puts the allocation in.
It is the one-liner for the 90% case, where the message comfortably fits in memory:
OStream.bytes is therefore the whole message here rather than a not-yet-flushed tail, and no write reports
BUFFER_FULL. It is an ordinary streaming stream in every other respect: OStream.setBuffer works and means what it always means โ the not-yet-flushed bytes in the old buffer are dropped and encoding continues into yours, which the accumulator then grows in turn.