no matching function for call to getline std istream

#No matching function for call to getline std istream code#

It has some helpers that let you build iterators from a fairly minimal interface. This is a painful and verbose programming exercise, but Boost.Iterator can help. Instead, we need to write our own iterator type, and build a valid range out of that. Unfortunately, we can’t press istream_interator into service for us. We need something like that, but for lines.

You can create a range out of istream_iterators that pulls characters - or ints or whatever - from an istream on demand. The STL already has such a thing: std::istream_iterator. Instead, getlines does something smarter: it returns a lazy range.Ī lazy range is something that generates elements on demand.

That would be (a) dumb, (b) expensive, and (c) impossible in practice since a potentially infinite number of lines could be read from an istream. What does my getlines function return? Surely it doesn’t fill in a std::vector of string‘s and return that. (More on that later.) It also doesn’t suffer from the performance problems of my first attempt, although it takes some work to see why. Not only is it easier to use (look ma! one fewer line!), it doesn’t force a two-step initialization of any objects, and ranges and range operations compose.

Take a look: for(std::string& buf : getlines(std::cin)) Then it hit me: std::getline is the wrong API! It should be called getlines (plural), and it should return a range of strings.

#No matching function for call to getline std istream code#

What is this code doing? It’s reading a bunch of lines and processing them one at a time, right? You might even say, it’s returning a range of lines. I studied the problematic code some more: std::string buf Out parameters are ugly and awkward to use, they hurt API composability, they force you to declare objects and initialize them in separate steps, they cause acne, etc. (It turns out he prefers a different design, and we’ll be arriving at a similar conclusion.) I wanted to continue the discussion. Back To The Drawing Boardĭuring GoingNative, Andrei left getline there. After a few times through the loop, buf will probably be big enough to hold whatever lines will be read next, and that space can be reused with no further allocations. Well, it’s creating a new string each time, duh. Now consider what this code would be doing if, instead of taking buf as an out parameter, getline created a new string each time and returned it by value. But consider this use of getline: std::string buf You might think that because of move semantics, we don’t have to worry about the lousy performance of returning expensive collections by value, and you’d be right. But even overlooking that, there’s an issue here.

That’s nice, right? I mean, aside from the obvious shortcoming that now you can’t tell whether getline succeeded or not. That allows a more concise, natural usage, and doesn’t force the user to create a named variable: use_line(getline(std::cin)) Return buf // This gets moved out efficiently So, perhaps a better API design would look like this: // Should getline look like this instead? In C++11, standard containers like std::string are moveable, so returning one by value is darn near free. APIs designed like this have traditionally had the benefit of being efficient, at the expense of some awkwardness at the call site: std::string buf They also know why the interface is designed this way: Because containers like std::string are too expensive to copy to consider returning one by value. Seasoned programmers recognize this pattern: The function takes the buffer by non-const reference and fills it in. Std::istream& getline(std::istream& sin, std::string& buf) It was about the design of std::getline: // Read a line from sin and fill in buf. At GoingNative back in September, Andrei Alexandrescu posed an interesting question about API design and C++11 that has had me scratching my head for a month.