Paul Eggert wrote:
> More and more this is starting to sound like a loser situation.
> Perhaps we should give up on these predecessor #includes entirely, and
> warn users that they must include minmax.h after they include any file
> that might possibly include a system file.
I don't wish to go back to the days where we had to think about order of
#includes. Like "we need <sys/types.h> before <regex.h>" and similar.
The following heuristics works very well in practice:
- First comes the #include "..." specifying the module being implemented.
- Then come all the #include <...> of system or system-replacement headers,
in arbitrary order.
- Then come all the #include "..." of gnulib and private headers, in
arbitrary order.
This little problem with minmax.h is now fixed, and not enough of a problem
to depart from this practice.
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
