You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do not rely on transitive inclusions. This allows people to remove no-longer-needed #include statements from their headers without breaking clients. This also applies to related headers - foo.cc should include bar.h if it uses a symbol from it even if foo.h includes bar.h.
The second part about including the direct dependencies in the source file regardless of the corresponding header, contradicts with cpplint. When cpplint is run on a source file, it counts the includes in its corresponding header file as included.
The policy is that if you #include something in foo.h you don't need to
include it again in foo.cc. Here, we will look at possible includes.
Which rule should be followed?
The text was updated successfully, but these errors were encountered:
It's easier for IDEs and other tools to follow the simpler rule in the
style guide ("is this symbol provided by a file #included directly in this
file?"), so we'd prefer the written rule not the legacy behavior in cpplint.
On Sun, Jan 29, 2023 at 11:42 AM Geoffrey Viola ***@***.***> wrote:
This issue comes from cpplint#218
<cpplint#218>
The Google C++ Style Guide
<https://google.github.io/styleguide/cppguide.html#Include_What_You_Use>
states that
Do not rely on transitive inclusions. This allows people to remove
no-longer-needed #include statements from their headers without breaking
clients. This also applies to related headers - foo.cc should include bar.h
if it uses a symbol from it even if foo.h includes bar.h.
The second part about including the direct dependencies in the source file
regardless of the corresponding header, contradicts with cpplint. When
cpplint
<https://github.com/cpplint/cpplint/blob/fa12a0bbdafa15291276ddd2a2dcd2ac7a2ce4cb/cpplint.py#L6127-L6128>
is run on a source file, it counts the includes in its corresponding header
file as included.
The policy is that if you #include something in foo.h you don't need to
include it again in foo.cc. Here, we will look at possible includes.
Which rule should be followed?
—
Reply to this email directly, view it on GitHub
<#757>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7CRX6C42IQPX2WOPDCO53WU2MYVANCNFSM6AAAAAAUKKXV4Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
. Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...). And I encourage
you to feel free to do the same.
This issue comes from cpplint#218
The Google C++ Style Guide states that
The second part about including the direct dependencies in the source file regardless of the corresponding header, contradicts with cpplint. When cpplint is run on a source file, it counts the includes in its corresponding header file as included.
Which rule should be followed?
The text was updated successfully, but these errors were encountered: