Usually, you'd allocate one instance of stringstream per model loader, then use that.

That means, that it'll grow to the size of largest element, after which, no copies will be performed anymore. The fact that it allocates for each value is your own choice in this case.

The author of this paper is referring more or less to what I'm asking about when he says on page 27: "Since istreams want to read from objects, and not arbitray data, ...", then on page 30: "Examining the source and disassembly of the various methods showed that the ifstream IO, under Visual C++, simply spent a lot of time doing housekeeping". This and other sources like it helped confirm what I already suspected about std streams: they generally aren't ideal for quick operations such as this. I'll restate my original question and say that if anyone knows differently, please let me know.

Once again, thanks for your replies.

Quote:Original post by jorgander
regular strcmp: strcmp(first, second) == 0
std string: std::string(first).compare(second) == 0

strcmp() probably does not copy anything, where as std::string probably makes a copy during construction.

But if you were doing things sanely, you would have already had std::string objects to compare.

You should also be aware that std::string is probably smarter about copies than you think. It can very often do things faster, too, because it carries length information around with it: if you do iterated strcat() calls, for example, you're constantly implicitly re-strlen()ing, and iterating through the string each time for that. You might be smart enough, when concatenating things in a loop to keep track of the "end point", but when you start doing things across function calls, you find you need to pass a second parameter for the length... and then you get the idea to bind these two things together in a struct... and before you know it, you've reinvented the wheel (probably badly).

And BTW, you don't need to compare them like that: with std::strings, you can just write first == second. Imagine that!

I think this illustrates something important: instead of looking for something natural, your C background guides your eye to the first thing that looks vaguely like the interface of the C equivalent, which is constrained by that language. This is the same phenomenon that leads to abominations like 'for i in range(len(container)):' in Python. I think of this as brain damage. Regrettably, it's very, very common.

Oh, and just for the heck of it - I would have written the original example as something more like (not tested):

// A wrapper I like to keep handy. Caller is responsible for checking stream// state or setting exception flags, according to how it wants to do things.template <typename T> extract(std::istream& is) {  T result; is >> result; return result;}// FIXME: needs a more descriptive function name.std::pair<float, bool> Parse(const std::string& Value) {  std::stringstream temp(Value);  temp.exceptions(std::ios::failbit);  return std::make_pair(extract<float>(temp), Value[Value.length() - 1] == '%');}

I think you can do something like this to avoid memory allocation for copy of Value inside stringstream: