c2c,
It seems to me, not knowing enough about your application, that if you are not hyper-sensitive about scalability, and your first paragraph above seems to suggest that you are not, or you would avoid blocking APIs like .get(), the cost of creating a new stream buffer each time through the loop shouldn't be prohibitively high.
If you are hyper-sensitive about scalability, then storing data in STL strings or vectors is out of the question, period, since they progressively reallocate the underlying storage and copy data. In that case, using a raw-pointer buffer may be the way to go -- there should be no allocations that you don't see, but you have to size it large enough to hold the longest line. With that solution, just create the underlying storage once, then create the stream buffer from that storage each time through the loop, a super-cheap operation. The downside of that is that you have to manage the lifetime of the underlying storage yourself.
Niklas
It seems to me, not knowing enough about your application, that if you are not hyper-sensitive about scalability, and your first paragraph above seems to suggest that you are not, or you would avoid blocking APIs like .get(), the cost of creating a new stream buffer each time through the loop shouldn't be prohibitively high.
If you are hyper-sensitive about scalability, then storing data in STL strings or vectors is out of the question, period, since they progressively reallocate the underlying storage and copy data. In that case, using a raw-pointer buffer may be the way to go -- there should be no allocations that you don't see, but you have to size it large enough to hold the longest line. With that solution, just create the underlying storage once, then create the stream buffer from that storage each time through the loop, a super-cheap operation. The downside of that is that you have to manage the lifetime of the underlying storage yourself.
Niklas