Limiting the range for std::copy with std::istream_iterator

Question

I have constructed a minimal working example to show a problem I've encountered using STL iterators. I'm using istream_iterator to read floatss (or other types) from a std::istream:

#include <iostream>
#include <iterator>
#include <algorithm>

int main() {
   float values[4];
   std::copy(std::istream_iterator<float>(std::cin), std::istream_iterator<float>(), values);
   std::cout << "Read exactly 4 floats" << std::endl; // Not true!
}

This reads all possible floatss, until EOF into values, which is of fixed size, 4, so now clearly I want to limit the range to avoid overflows and read exactly/at most 4 values.

With more "normal" iterators (i.e. RandomAccessIterator), provided begin+4 isn't past the end you'd do:

std::copy(begin, begin+4, out);

To read exactly 4 elements.

How does one do this with std::istream_iterator? The obvious idea is to change the call to std::copy to be:

std::copy(std::istream_iterator<float>(std::cin), std::istream_iterator<float>(std::cin)+4, values);

But (fairly predictably) this doesn't compile, there are no candidates for operator+:

g++ -Wall -Wextra test.cc
test.cc: In function ‘int main()’:
test.cc:7: error: no match for ‘operator+’ in ‘std::istream_iterator<float, char, std::char_traits<char>, long int>(((std::basic_istream<char, std::char_traits<char> >&)(& std::cin))) + 4’

Any suggestions? Is there a correct, "STLified" pre-C++0x way to achieve this? Obviously I could just write it out as a for loop, but I'm looking to learn something about the STL here. I half wondered about abusing std::transform or std::merge etc. to achieve this functionality somehow, but I can't quite see how to do it.

Grant

+1 for a Short Self-Contained Complete Example (see sscce.org). – Paring

@Rob - I'd always used the term MWE for minimal working example, but that's quite a nice way of describing it especially with helpful text at that URL. – Grant

Related: stackoverflow.com/questions/3829885 – Zephyrus

Answer 1

As you requested a non-C++0x solution, here's an alternative that uses std::generate_n and a generator functor rather than std::copy_n and iterators:

#include <algorithm>
#include <string>
#include <istream>
#include <ostream>
#include <iostream>

template<
    typename ResultT,
    typename CharT = char,
    typename CharTraitsT = std::char_traits<CharT>
>
struct input_generator
{
    typedef ResultT result_type;

    explicit input_generator(std::basic_istream<CharT, CharTraitsT>& input)
      : input_(&input)
    { }

    ResultT operator ()() const
    {
        // value-initialize so primitives like float
        // have a defined value if extraction fails
        ResultT v((ResultT()));
        *input_ >> v;
        return v;
    }

private:
    std::basic_istream<CharT, CharTraitsT>* input_;
};

template<typename ResultT, typename CharT, typename CharTraitsT>
inline input_generator<ResultT, CharT, CharTraitsT> make_input_generator(
    std::basic_istream<CharT, CharTraitsT>& input
)
{
    return input_generator<ResultT, CharT, CharTraitsT>(input);
}

int main()
{
    float values[4];
    std::generate_n(values, 4, make_input_generator<float>(std::cin));
    std::cout << "Read exactly 4 floats" << std::endl;
}

---

If you wanted to, you could then use this generator in conjunction with boost::generator_iterator to use the generator as an input iterator.

Douce

Interesting, as generate_n guarantes that only n call to operator() are performed, and thus you don't have the count problem that copy_n might exhibit. Also, if specialized for std::cin, one can avoid the predicate and use a simple function (template <typename T> T get() { T t = T(); std::cin >> t; return t; }). Furthermore, it allows checking the state of the input (std::cin) easily. – Ghastly

I accepted this answer on the grounds of non C++0x-ness, combined with avoiding the problems discussed with copy_n and input iterators. – Grant

Answer 2

Take a look at std::copy_n 

Dyspepsia

@Igor Nazarenko : Fair, but you should note that this algorithm is new to C++0x, and not available in older compilers' standard libraries. – Douce

Ah that C++0x part might be a problem for me here then and would explain why I didn't spot it in my C++98 era STL book. Any Non C++0x solution? I had a look to see if there was a cunning way of (ab)using something like std::transform or std::swap_range to achieve this, but I couldn't see anything obvious. – Grant

I didn't realize it's not in C++98 :-) It's in GCC since ~2008, I guess I'm spoiled. Which compilers do you need to be compatible to? – Dyspepsia

@Igor I'm using gcc 4.4 personally, but I had avoided C++0x so far in this project as I have a strong suspicion someone will want to compile it with old(ish) VS (newer than 6 though) in the near future and I was under the impression that it would be asking for pain if I did. – Grant

Use of copy_n has its own problem with the number of times it increments the istream_iterator https://mcmap.net/q/504436/-std-istream_iterator-lt-gt-with-copy_n-and-friends In this case it might copy 4 floats, but might also read 5 from cin! – Sleuth

It's only present from VS 2010 on. – Dyspepsia

also on a side note slightly curious as to how you're supposed to check for success with copy_n and istream_iterators - testing the iterator returned from copy_n with std::istream_iterator<float>() (i.e. end) isn't sufficient is it? And the values after any failure would be uninitalised presumably. – Grant

@Bo Persson - that's a killer then! Seems like a bit of a flaw really given that the documentation for copy_n implies the only case you'd ever need it over just copy is for input iterators instead of forward iterators. – Grant

@awoodland: actually you'd would need it for anything that does not support +, which is anything apart from RandomAccessIterator. InputIterator are tricky though :/ – Ghastly

@Matthieu M. : Where are you coming up with the need for operator+? Both copy and copy_n take input iterators, not random access iterators. – Douce

@Douce - you need an operator+ if you want to generate an end for the range that's n elements passed the first iterator instead of just calling end() on a container etc. – Grant

@awoodland : Not necessarily; std::advance works on input iterators. – Douce

@ildjarn: from @awoodland post, where he tried to use it so that he could specify a "proper" range for the copy algorithm. You cannot build a proper range without actually reading that whole range except with RandomAccessIterator (whether using + or advance). – Ghastly

@ildjarn: advance works on InputIterator, but you cannot build a range with it. – Ghastly

Answer 3

If you don't have std::copy_n available, it's pretty easy to write your own:

namespace std_ext { 
template<class InputIterator, class Size, class OutputIterator>
OutputIterator copy_n(InputIterator first, Size n, OutputIterator result) {
    for (int i=0; i<n; i++) {
        *result = *first;
        ++result;
        ++first;
    }
    return result;
}
}

Loving

Actualy, your example might have the bug that originated the discussion @Bo Person linked: ie, first being incremented n times, and thus reading n+1 values. Howard Hinnant posted the a commit of the patch for libc++ in one of the comment, giving an implementation that does not have the issue: lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/… – Ghastly

@Matthieu: I may have to talk a bit with Howard about that. It looks to me like the "corrected" version returns input+n-1, where it's required to return input+n. That may be more useful behavior under some circumstances, but unless I'm misreading, it still looks like it's violating a requirement. – Loving

@Jerry : Is there any followup to your last comment? – Douce

@ildjarn: Yes -- I'd misread the code; it does (correctly) return input+n. – Loving