giomm API question

["Jonathon Jongsma" <jonathon quotidian org>]

Right now, the Gio::InputStream class has a read function which takes
a standard C data buffer:

gssize InputStream::read(void* buffer, gsize count);

Since we use C++, it might be nice to be able to read data into a
std::string instead of a C data buffer, so I was going to add a
overloaded convenience function to do so:

gssize InputStream::read(std::string& buffer, gsize count);

That function needs a 'count' argument, because it's not intended to
just read to the end; there's a separate read_all() function that does
that.

But the issue is, the std::string overload will need to do some extra
dynamic memory allocation internally that might not be obvious to the
caller.  For example (simplified):

gssize InputStream::read(std::string& buffer, gsize count)
{
  // 'count' is not a compile-time constant so many compilers won't let you
  // do char[count] c_buffer; we must allocate dynamically
  char* c_buffer = new char[count];
  gssize sz = g_input_stream_read (gobj(), c_buffer, count, ...);
  buffer.assign (c_buffer);
  delete[] c_buffer;
  return sz;
}

If a user did the conversion to std::string themselves, it will
require a little bit more code from the API user, but they could
allocate the buffer on the stack if desired.  e.g.:

char buffer[100];
stream->read((void*)buffer, 100);
std::string s(buffer);

Obviously, adding the overload doesn't preclude anybody from using the
raw pointer method, but it is not necessarily obvious that the
convenience function may be less efficient than doing the std::string
conversion themselves.  Do people feel that this convenience function
is worth the 'hidden' cost it may add to the code?
-- 
jonner