> On July 30, 2015, 4:45 p.m., Vinod Kone wrote:
> > src/tests/containerizer/launcher.hpp, lines 19-37
> > <https://reviews.apache.org/r/36929/diff/1/?file=1024924#file1024924line19>
> >
> >     why did you remove these headers?
> >     
> >     i think we decided to explicitly include all the headers that are used 
> > in a file instead of depending on transitive includes.
> 
> Jie Yu wrote:
>     Is there a discussion somewhere? I think explicitly including all headers 
> make it hard to maintain (you'll need to adjust the header when the dependent 
> header changes). Also, it slows down the compilation.
> 
> Vinod Kone wrote:
>     This is the pattern we followed in the code base. I think it improves 
> readability and avoids gotchas. For example, it is not clear at all that the 
> headers you kept provide a string or a vector definition (What if those 
> headers don't "#include <string>" at a later time?). This is the relevant 
> blurb from the google style guide
>     
>     ```
>     You should include all the headers that define the symbols you rely upon 
> (except in cases of forward declaration). 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, unless foo.h explicitly demonstrates its 
> intent to provide you the symbols of bar.h. 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).
>     
>     ```
>     
>     Some relevant discussion: 
> http://www.mail-archive.com/dev%40mesos.apache.org/msg32694.html

I have to disagree. C++ is not like Java, we don't have an automated tool to 
help you include all necessary headers (java does). As a result, that makes 
maintaining the includes very tedious. Any time someone is doing a refactor, 
he/she has to manually check all the includes to make sure it's up-to-date. 
Unless we have an automated tool to help you include all necessary headers, I 
think having less includes makes it easy to maintain.

The pattern I suggest here is:
```
base.hpp

#include <string>

class Base {
  virtual void foo(const string& str);
};

derived.hpp

#include "base.hpp"

class Derived : public Base {
  virtual void foo(const string& str);
};
```

We suggest don't include `<string>` in derived.hpp. This does not violate 
google style as it states: "unless foo.h explicitly demonstrates its intent to 
provide you the symbols of bar.h". I think here, base.hpp clearly demonstrates 
its intent to provide you the symbols for all its public interfaces.


- Jie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36929/#review93599
-----------------------------------------------------------


On July 30, 2015, 12:14 a.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36929/
> -----------------------------------------------------------
> 
> (Updated July 30, 2015, 12:14 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Fixed a few issues in test launcher header.
> 
> 
> Diffs
> -----
> 
>   src/tests/containerizer/launcher.hpp 
> b80e84196f8b494e6e5a3c96c86f63fe432a7bb0 
> 
> Diff: https://reviews.apache.org/r/36929/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to