使用 printf 和 C++ 迭代器

Question

I'm not clearly understanding what's happening when I use std::printf with an iterator in this context:

#include <string>
#include <vector>
#include <list>
#include <cstdio>
int main() {
   std::string str{"hello, world"};
   std::printf("%s\n", str.begin()); // prints "hello, world"
   std::vector<char> vec(str.begin(), str.end());
   std::printf("%s\n", vec.begin()); // still same output
   std::list<char> lst(str.begin(), str.end());
   std::printf("%s\n", lst.begin()); // weird ascii outputs ???
}

I also used <stdarg.h> utilities to simulate printf's behavior and it looks like it still works even with va_arg(ap, char*) and behaves the same way as the code above, and I got couple of questions. Does it work on arrays that are contiguous (with a RAI iterator)? or it's UB? Why even va_arg will allow such thing, is there some implicit conversions?

Answer 1

TL;DR: It's all invalid C++ , since std::printf doesn't have a type safe API. Passing references to non-POD objects as std::printf arguments is always invalid : printf has a C API.

What's happening in all cases is undefined behavior: you should not be writing code like that. The language spec itself tells you nothing about what to expect. Such code is a bug and would fail any sensible code review.

For the case of std::string and std::vector iterators, they happen to have the same size, value, layout, and parameter passing convention on your platform as a const char * that printf expects, and they happen to contain addresses of the beginning of the string/vector, respectively. Both std::string and std::vector<char> lay out the data array identically, ie the elements are contiguous, and coincidentially the memory block in std::vector has a zero at the end of the string, so this happens to work. Maybe it only works because you build in debug mode:)

For the case of std::list iterator, it probably happens to contain a pointer to either the header of the list's data block, or a pointer to the beginning of std::string wrapped in the list item, and thus you get nonsense output that nevertheless doesn't cause an invalid memory access, since the equivalent pointer points to some allocated memory area and is otherwise valid. This is a consequence of implementation details on your platform, of course. There are platforms and build options where that code will just crash. And no, you can't even depend that it will crash dependably. That's why UB is pretty bad.

On your platform, std::printf("%s\n", *lst.begin()); would probably be just as bad of a bug yet happen to "work", since *lst.begin() produces a reference to std::string , and such a reference usually is laid out and passed around like a pointer would be. This is still UB of course, so don't do any of it!