I recall some "detail" code in Boost that does exactly what I want:
allocate a probably-good-enough size on the stack but switch to heap if
needed. But I can't remember where I saw it.
Looking around, I came across mentions of Boost.AutoBuffer by Thorsten
Ottosen, but all links are dead.
I have been a bit busy, but I plan to get it going soon.
It seems that there is an unofficial version in
boost/signals2/auto_buffer.hpp
regards
-Thorsten
Thanks. I found that copy, and it had your name on it too, so I figure it must be the
same code.
I like the feature of making an "uninitialized" expansion, too. In particular, for
dealing with "out" parameters of OS API calls or legacy code, I want to naturally give my
buffer as a vector.data(). But it is annoying to me that it needs to zero out the whole
buffer just to pass it to code that is expecting uninitialized area for output, anyway.
Making "uninitialized" part of this class is natural since the hopefull stack space is
used in the same context. And being your own brand new class, it doesn't fiddle with any
standard library code to achieve it. <g>.
However, I think the existing public API could be improved a little in this manner. Here
is what I ended up doing:
auto_buffer buf;
buf.uninitialized_grow (buf.capacity()); // start out with as much as fits on the
stack (256 elements).
int result= ::GetWindowTextW(hWnd,buf.data(),buf.size());
I had to figure out that capacity was the correct way to get the stack-based size, but
that's a documentation thing. I called uninitialized_grow rather than
uninitialized_resize because I know it was originally zero; the passing of the delta which
looks like the new size too bothers me a little. But my real point is that I can't
command an uninitialized size on the constructor. The normal constructor arguments work
the same as vector, and can take an initial size and a value that defaults to T(). It
would be much clearer and simpler for this use case to say what I want directly on the
constructor. I think it would be natural to give a special flag where the value would
normally go:
auto_buffer buf1 (500 /*count*/, L' ' /* value */); // same as std::vector
auto_buffer buf2 (500, non_initialized); // looks like a "value", but
overloaded ctor.
and it would be unambiguous to give the non_initialized flag alone, taking the maximum
pre-allocated size.
auto_buffer buf3 (non_initialized);
And, as a further trick, it is a cheap failsafe to initialize just the last element with a
sentinel value. This is not as inefficient as needlessly initializing the whole buffer,
but adds a cheap fallback just in case the call that was supposed to write to the buffer
didn't to anything.
auto_buffer buf4 (non_initialized, L'\0'); // the last index is set to zero
In general, any signature that takes a T after the special non_initialized_t takes it to
be a sentinal initialization, and two such arguments are for last and first index (only).
Or, since the same value ought to be used for both, maybe it always does first and last,
or uses different special flag names for non_initialized-except-for...
With the ctor signature it is clear what is being done, and I don't need to explicitly
reference the stack-based size separately from the template argument that gives it. And,
it generates simple direct code to set it up that way rather than setting it and changing
it around again. I don't think the optimizer would figure out that capacity() at this
point means the stack-based size, and then optimize out the large case from the resize code!
Meanwhile, should the class support uninitialized sizing ONLY for types that support it?
That is, PODs, primitives, classes without destructors, and in general those that are
marked as such via a metaprogramming type trait.
