Minimize <iosfwd>

[Paolo Carlini]

Hi all, hi Zack,

I will not do much work on the library during the next week or so...

> Do you have any thoughts on declaring allocator<T> and char_traits<T>
> (what we currently use stringfwd for)?  I would really like to get
> <iosfwd> down to just what the standard requires it to declare...

In my opinion, a very small iosfwd is a worthwhile goal, provided of 
course we follow the consistent strategies pointed out by Benjamin, 
refined over the years. About avoiding <bits/stringfwd.h>, I don't know, 
seems small to me, my knee jerk reaction to your question would be that 
probably we'd like to use very small forward declaration headers like 
stringfwd.h more, not less (probably, I'm myself "guilty" of having 
quickly declared char_traits and allocator in a couple of places and I 
would rather *remove* that) Let's measure and see...

The above leads to my main point here: if we are talking about streams 
and locales, I would say probably there is more urgent work to do: for 
example the various facets in locale_facets.h and locale_facets.tcc 
could be split to separate files: the important observation is that 
istream and ostream  only use ctype and num_get, num_put. Likewise, 
fstream uses only codecvt. Maybe there are pitfalls, but I'm anyway 
confident we could easily remove about 100 - 150 KB from <iostream> for 
example, for the benefit of *so* many users. When I will be back from 
the ISO Meeting I want to give that a try (in parallel with other things)

Minor tweaks are also possible, for example I have patches to remove 
<typeinfo> from locale_facets.tcc, very small but "misleading" in my 
opinion, because currently we use __throw_bas_cast(); another one 
removes remaining uses of <csdlib> only for the sake of abort() and 
replaces it with __builtin_abort() (undocumented? But appears to work fine).

Well a final note of optimism: early today I quickly compared various 
releases and all the new features notwithstanding, the headers now in 
mainline are the smallest in v3 ever, much smaller than in 3.0.4, for 
example. Thus I would say let's take time, always regtest very well, and 
proceed incrementally: people will like 4.3.0 anyway from this point of 
view ;)

Paolo.