An array of data and the size of the array of data are almost always passed together. If they are passed together so frequently, they should really be wrapped so they can't *not* go together.
At the simplest:

struct ByteBuffer
{
   size_t bytes;
   Byte *data;
};

But really, arrays of byte data is used frequently enough that it should have a nice class with plenty of helper functions, proper constructors/destructors move-semantics and all that.

Write one, use an existing one, or take mine:
ByteBuffer class (header)
ByteBuffer class (source) (just replace the logging and asserts, and it'll compile fine with no dependencies)

Really, that has the same advantages and disadvantages of a vector, without being templated. I get your point, though.

Vectors are really nice for alot of purposes, including occasionally using them as byte buffers. But since byte buffers are a common use, it's also nice having a custom class for it with specialized functions - for example, my class provides an interface for non-owning buffers or taking ownership of existing buffers.

But I must've misunderstood your question if that wasn't what you were looking for.

After re-reading your posts, I think I get what you are saying. My answer would still be to use a small class that wraps the result, that can destroy itself when it goes out of scope.

getKey() would create and return the class, and the class will have a pointer to the data and know how many elements it contains. A vector would work for that, or a small custom class. You could even return a std::pair<size,pointer> but personally I dislike that - and the caller would have to manually free the pointer, which isn't ideal.

If the caller doesn't know the size of the buffer he needs to create, why not let the function create the buffer and return both it and the size at the same time?

Vectors are really nice for alot of purposes, including occasionally using them as byte buffers. But since byte buffers are a common use, it's also nice having a custom class for it with specialized functions - for example, my class provides an interface for non-owning buffers or taking ownership of existing buffers.

Yeah, I do acknowledge that the special class has desirable features for maintaining a generic byte buffer has many benefits. Looking over the header, I like the ability to make child objects that point to a subset of the buffer, and other useful functions.

If the caller doesn't know the size of the buffer he needs to create, why not let the function create the buffer and return both it and the size at the same time?

The caller could find out, with a query function like outlined above. However, one of the biggest reasons is that the caller could know: if they specify the size of the keys, they know how large the buffer should be, and can pre-allocate and re-use the buffer over and over.

I guess querying for the size, then passing a pointer and size of a buffer is my best option. I guess my biggest priority was cutting down on allocation requirements, while requiring fewer steps for the caller, but it's already nearly as good as it will get. The discussion did give me some good ideas about another project, though.

Thank you all, for your time.