[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Include what you use
From: |
Greg Chicares |
Subject: |
Re: [lmi] Include what you use |
Date: |
Wed, 27 Oct 2021 18:03:05 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
On 10/27/21 12:06 PM, Vadim Zeitlin wrote:
> On Tue, 26 Oct 2021 23:41:12 +0000 Greg Chicares <gchicares@sbcglobal.net>
> wrote:
>
> GC> [...] In some cases it duplicates what
> GC> the source already says:
> GC>
> GC> iwyu: #include <climits> // for UCHAR_MAX
> GC> lmi: #include <climits> // UCHAR_MAX
> GC> iwyu: #include <cstdio> // for EOF
> GC> lmi: #include <cstdio> // EOF
> GC>
> GC> but it's very nice to have an automatically-generated touchstone
> GC> to verify that.
>
> FWIW I thought about converting its output to lmi-compatible form by just
> passing it through sed/awk/rakudo/deep-learning-AI to get rid of "for" and
> start the comment at 41st column -- this would be simple to do, but mostly
> (only?) useful if we wanted to use it automatically, e.g. to compare the
> lines output by the tool with the actual lines in the sources.
I don't think we'd want to use it in quite that way. For example:
#include <string> // for string
That's obvious. I do like to be able to press '*' (shift-8) while
the cursor is on "string", in order to judge whether <string>
really should be included; but I can do that without the comment.
Similarly, I'd omit this comment and press 'g*' on "limits" here:
#include <limits> // for numeric_limits
Then, if 'g*' finds nothing, that tells me I should consider
not including the header.
Here, I'd have to think about which "operator|' is meant:
#include <ios> // for ios, operator|, ios_base, ostringstream
and I'd still want to include <sstream> for std::ostringstream.
The tool's greatest usefulness here is to make sure that only
appropriate headers are included; I don't spend much time
thinking about what's in class std::ios std::ios vs. std::ios_base.
> GC> > miscellany.cpp should add these lines:
> GC> > struct tm;
> GC>
> GC> I wonder why it would complain here:
> GC> std::tm const*const t1 = std::gmtime(&t0);
>
> Sorry if I'm misunderstanding your question,
I thought it was suggesting that, in order to use std::tm,
merely including <ctime> wouldn't suffice, and that it
would also be necessary to declare struct tm explicitly.
> but to me it seems clear
> enough: the tool wants to forward declare std::tm because it must be
> declared here and forward declaration is enough, i.e. it's unnecessary to
> include the full <time.h> here.
But would a simple
struct tm;
declaration suffice? And shouldn't that be
namespace std {struct tm;}
? But wouldn't that full declaration be illegal? And wouldn't
we still need <ctime> for the declaration of gmtime(), or does
this tool want me to forward-declare that, too?
In less time than it takes to pose those questions, let alone
answer them, I can simply type
#include <ctime>
and know I'm in full compliance.