Comment 119 for bug 1142213

(In reply to comment #90)
> > So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically.
> Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much
> more than to 2KiB, so this inefficiency can be neglected in favor of cleaner
> code.

Depends how long the string you want to read, right ?
in principle runCommand could be re-used elsewhere for any type of command (like "cat very_long_file_with_no_linebreak")

>
> > There is No conversion from const char* to std::string in the current code
> > the call runCommand( "..." ) implicitely calls the std::string directly
> > as for the call string.c_str() it access directly the const char* stored internally in the string
> Why no conversion? You call runCommand("str") and this calls
> std::string("str") potentially doing some initialization there.

yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer).

> And then you
> call a function which needs const char*, in which case although you don't
> convert, but this still is redundant.
redundant with what ?
std::string is a pointer to const char* with a proper destructor and copy constructor. Nothing more. (well, more or less :))

>
> > All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have
> > to (namely when calling gtk, glib or other functions).
> Yeah I do understand this, but you have a POSIX function here - this is just
> like gtk function, and we pass string literal here, for which std::string
> has no advantage at all.

But that's the point: disregarding of the internals of the function, I don't want it to spread.
I do not what to have to ask myself, every time I call runCommand, whether I need to free the string or not (disregarding whether it uses posix or gtk in there).

The idea is not about what's done internally, but what to expect when called by the rest of the world, without knowing what's done internally. With passing std::string, I know I don't have to care about allocation deallocation. That's the same spirit behind my writting of the oxygencairosurface, pattern, context; the timers, etc. In general, the more "self-deallocating" things you use for the arguments in your methods, the more stable your code will be. (my oppinion at least)

In any case, I'm not sure here is the right place to have this discussion.