On Sunday April 26 2020 16:58:10 David Faure wrote:

>> As a side-note, I'd even argue that
>> it would make sense to provide an all-inclusive header per framework, just
>> like Apple's frameworks do.
>
>It's said to improve compilation times with precompiled headers, but in 
>practice nobody knows if the person compiling the code has that, so I fail to 
>see the point.

The possibility to use precompiled headers is only an argument here when 
increased compilation times are brought up as an argument against such a 
header. But that's not really an argument if you can continue to use just the 
headers you need.
(But FWIW, in my experience it's much more efficient to use ccache, possibly in 
combination with distcc.)

>Who needs all of <KCoreAddons>? Nobody.

I could just as well maintain that nobody needs any of that particular 
framework ;) But the question isn't who needs all of. People including 
<AppKit/AppKit.h> or (better example) <Accelerate/Accelerate.h> also rarely 
need all of those frameworks. It's just a convenience: no need to jump back and 
forth between your editing location and the file preamble (after deciding if 
you want the required additional header in the implementation file or in the 
corresponding header file), and no need to maintain a long list of include 
statements which ideally you should prune every time you stop using a certain 
class. (Just how often do people forget to remove the corresponding header?)

I'm not saying that either approach is better - they both are, just for 
different people ;)

>I wouldn't call this "purely by chance". I set -Wundef there for a reason :-)

I still call me seeing the warning a pure chance given the fact it's there. The 
fact of me seeing it if it were not there would also be a pure chance ... 
hopefully close enough to 0 ;)

Seriously, catching this among the very copious output of multiple concurrent 
compiler jobs echoing their incredibly long command lines to the terminal is 
really rather unlikely unless most files generate several of these warnings.

>OK, talk to the KDevelop people then :-)

Done!

R.

Reply via email to