container.begin()+1 validity for empty container vs container.end()-1

Question

I was banging my head against a wall trying to figure out why this implementation of an operator << overload for printing vectors with cout was causing segfaults if used with empty vectors.

template<typename T>
ostream& operator << (ostream& out, const vector<T>& v) {
    out << '[';
    for(auto p=v.begin(); p<v.end()-1; ++p) {
        out << *p << ", ";
    }
    if(!v.empty()) {
        out << v.back();
    }
    out << ']'; 
    return out;
}

After some debugging I realized that the loop condition was returning true for empty vectors so I tried to fix it several ways until landing on this solution with the help of ChatGPT.

template<typename T>
ostream& operator << (ostream& out, const vector<T>& v) {
    out << '[';
    for(auto p=v.begin(); p+1<v.end(); ++p) {
        out << *p << ", ";
    }
    if(!v.empty()) {
        out << v.back();
    }
    out << ']'; 
    return out;
}

Notice the change in the condition of the loop essentially goes from v.start() < v.end()-1 to v.start()+1 < v.end() in the problem case of empty vectors. I tested the solution and found that it works fine now. I asked ChatGPT why this works and it basically told me that I should respect the valid range of vector iterators: [v.start(), v.end()]. Yet I find it curious that v.start()+1 results in correct behavior since in the case of empty vectors v.begin()==v.end() thus v.begin()+1 is outside of the valid range thus should be undefined behavior.

I asked again about the difference between accessing the range before v.start() and the range after v.end() and the response boiled down to its ok to do the latter but not the former since we are not dereferencing the iterator. But using this logic wouldn't it be fine if we did either? Shouldn't both be undefined behavior? Does this kind of thing apply to other types of containers that support iterators? Is container.end()+1 valid or not for arithmetic and comparison purposes?

Answer 1

Both approaches can work if the vector is tested first for empty. Otherwise, you are risking undefined behavior adding/subtracting the iterator values. Outputting the first element before the loop seems more readable. Inside the loop, the comma precedes the value's output.

If you can use the ranges library, the range-for is usable similarly using drop to hide the first element for the loop.

Here is a simplified demonstration and testing code:

auto main() -> int {
   std::vector vec{1, 2, 3};
#if 0
   vec.clear();
#endif

   if (!vec.empty()) {
      std::cout << vec[0];
      for (auto v = vec.begin(); v != vec.end() - 1; v++) {
         std::cout << ", " << *v;
      }
      std::cout << '\n';
   }
   if (!vec.empty()) {
      std::cout << vec[0];
      for (auto v = vec.begin()+1; v != vec.end(); v++) {
         std::cout << ", " << *v;
      }
      std::cout << '\n';
   }

   // If you can use ranges
   if (!vec.empty()) {
      std::cout << vec[0];

      for (auto v : vec | drop(1)) {
         std::cout << ", " << v;
      }
      std::cout << '\n';
   }
}

Update 1 & 2: I couldn't resist trying the latest std::print in C++23. Added simple std::println in response to comment. I didn't try it with CLang in Compiler Explorer because it wouldn't work on my system with GCC. Duh!

Live code:

if (!vec.empty()) {
    std::print("{}", vec[0]);
    auto drop_cnt = (vec.size() > 1) ? 1 : 0;
    std::println(", {:n}", vec | vws::drop(drop_cnt));
}

println("{:n}", vec ); // :n removes the surrounding []