https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
--- Comment #7 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #5) > So don't store them as filesystem::path objects then, store them as strings > and create a path as needed. Type system is here for a reason. And it has advantages to type something, which is naturally a path, as such, not as an arbitrary string. > GCC's implementation creates the path components eagerly, so that > path::iterator meets the requirements of a forward iterator, whereas the > libc++ implementation creates them lazily during iteration, and so is not a > valid forward iterator. It doesn't have to be. See standard 30.11.7.5: A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (27.2.6) except that, for dereferenceable iterators a and b of type path::iterator with a == b, there is no requirement that *a and *b are bound to the same object. Its value_type is path. > The implementations have different trade-offs. That is not a bug. Poorly considered trade-offs are called "bad design" ;) Besides, your implementation breaks the fundamental C++ design principle "you don't pay for what you don't use". now everyone has to pay x10 memory overhead even if they are not ever going to iterate over a path object. I agree, that is not a bug, in C++ world, its a pure crime ;)
