Date: Thu, 04 Jul 2024 10:56:08 +0200
On Wednesday 3 July 2024 17:20:35 CEST Jason McKesson via Std-Proposals wrote:
> But that's a problem with how the module was
> written.
The same can be said about header files too. No one has accused windows.h of
ever being a good design. Whoever thought it was a good idea to put everything
in one header in the early 1980s probably never considered how big it would
ever become. But it is there and people must deal with it.
Another bad example of big header files is the Standard: <algorithm> is huge.
Yet those are two separate problems. Windows.h pollutes the global namespace
left and right with macros and other global typedefs, while Standard Library
headers are slow to parse, though by definition don't pollute the namespace.
This implies one solution wouldn't fit all needs: controlling what one keeps
from a header wouldn't make parsing any faster.
And are there more headers besides windows.h that would clearly benefit from
this?
> But that's a problem with how the module was
> written.
The same can be said about header files too. No one has accused windows.h of
ever being a good design. Whoever thought it was a good idea to put everything
in one header in the early 1980s probably never considered how big it would
ever become. But it is there and people must deal with it.
Another bad example of big header files is the Standard: <algorithm> is huge.
Yet those are two separate problems. Windows.h pollutes the global namespace
left and right with macros and other global typedefs, while Standard Library
headers are slow to parse, though by definition don't pollute the namespace.
This implies one solution wouldn't fit all needs: controlling what one keeps
from a header wouldn't make parsing any faster.
And are there more headers besides windows.h that would clearly benefit from
this?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-04 08:56:14