4 ms·
From our (STL maintainer) perspective, <array> includes <algorithm> because it needs equal(), <iterator> because it needs reverse_iterator, and <tuple> because
by StephanTLavavej 12y ago
From our (STL maintainer) perspective, <array> includes <algorithm> because it needs equal(), <iterator> because it needs reverse_iterator, and <tuple> because it needs to provide get(). Minimal!
But yeah, it drags in a whole tree of headers. Minimizing this is possible, and we've taken steps to do so in the past, but it's a lot of work for possibly minimal benefit - user translation units tend to drag in many STL headers, especially if they're using precompiled headers like they should. We think our time is better spent fixing correctness bugs and implementing features.
- blt 12y agoI understand. We definitely want C++14 features first :) But it seems like some of the problems would be easy to fix. Like - istream_iterator is defined in <iterator>, so <iterator> needs to include <istream>, which has a huge subtree. Iterators are a much more "leaf" idea than input streams. Why doesn't <istream> include <iterator> instead? Or, <algorithm> gets most of its subtree via <memory>, which it needs for a few algorithms that use temporary buffers. That one is beyond your control... The standard should add an <algorithm_lightweight> header containing only algorithms that don't need extra memory. Or you could add your own such header to use internally.
- StephanTLavavej 12y ago> Why doesn't <istream> include <iterator> instead? Users must be able to include <iterator> by itself, and get istream_iterator. We do break things up into internal headers, we just haven't done that as much as possible. Come to think of it, equal() is defined in one of our central headers, so we should probably take advantage of that in <array>.