> "treat foo.hpp the same way as other project headers".
+1 This one may more easily to follow.

> 1) If you rely on symbols from bar.h, don't count on the fact that you 
> included
foo.h which (currently) includes bar.h: include bar.h yourself,
> 2) unless foo.h explicitly demonstrates its intent to provide you the symbols
of bar.h.
> 3) However, any includes present in the related header do not need to be 
> included
again in the related cc (i.e., foo.cc can rely on foo.h's includes).
I think most contributors have followed this for a long time?
+1 for "clarify this in the Mesos style guide"

On Wed, Dec 14, 2016 at 10:29 AM, Yan Xu <xuj...@apple.com> wrote:

> Another related practice we should standardize is that, Google style guide
> suggests here
> <https://google.github.io/styleguide/cppguide.html#
> Names_and_Order_of_Includes>
> :
>
> 1) If you rely on symbols from bar.h, don't count on the fact that you
> included foo.h which (currently) includes bar.h: include bar.h yourself,
> 2) unless foo.h explicitly demonstrates its intent to provide you the
> symbols of bar.h.
> 3) However, any includes present in the related header do not need to be
> included again in the related cc (i.e., foo.cc can rely on foo.h's
> includes).
>
> We obviously follow 1) but AFAIK we don't follow 2) and 3), instead we have
> been doing "include everything needed yourself, no exceptions".
>
> It would be great to clarify this in the Mesos style guide as well.
>
> ---
> @xujyan <https://twitter.com/xujyan>
>
> On Wed, Dec 14, 2016 at 10:14 AM, Yan Xu <xuj...@apple.com> wrote:
>
> > For a cpp file foo.cpp, our style guide instructs folks to put the header
> > foo.hpp at the top of the include list: https://github.com/apache/meso
> > s/blob/master/docs/c%2B%2B-style-guide.md#order-of-includes
> >
> > This is consistent with Google style guide but in reality most of the our
> > files follow the rule of "treat foo.hpp the same way as other project
> > headers".
> >
> > Since this rule has been introduced to the Mesos style guide I haven't
> > seen much adoption. Most committers still observe the "old" rule when
> > creating new files and have been instructing contributors to do the same.
> >
> > Given the current status I'd suggest we revert the style guide on this?
> > It's only adding confusion and I don't see the need to do a sweeping
> change
> > to the codebase to comply with the new rule.
> >
> > Thoughts?
> >
> > Yan
> >
>



-- 
Best Regards,
Haosdent Huang

Reply via email to