Re: #include file optimizer
On 08/11/09 20:18, Jonathan Thornburg wrote:
In an earlier posting in this thread, I wrote:
I'm suggesting that in this style the header file
(let's call it x.hh) should read
//
// prerequisites:
//<string>
//
//
// This class ...
//
class x {
std::string name;
public:
// whatever
};
I would like to hope that before writing #include "x.hh" a programmer
will first read enough of x.hh to understand the client API provided
by class x. In this programming style a prerequisite
#include<string>
is part of the "#include API", and is explicitly documented in x.hh .
Maxim Yegorushkin<maxim.yegorushkin@gmail.com> wrote:
In this case if the header start using a new class, say std::list<>, and
does not include<list>, this change breaks the compilation of all files
that include that header
In the headers-don't-include-other-headers style, the "prerequisites"
comment will now read
//
// prerequisites:
//<string>
//<list>
//
and all clients are required to update their source code accordingly.
In my personal opinion this is rather unsatisfactory.
With self-contained headers (headers that include other headers as
needed) a new header dependency only triggers client recompilation, but
no editing of clients required (provided interfaces don't change).
A good practice they use in boost to ensure that headers are
self-contained is that includes are normally ordered from most local
headers (project headers) to standard headers. This way a missing
include in a header causes a compile time error because standard headers
are less likely to have been included yet.
Example from boost/interprocess/mapped_region.hpp:
//////////////////////////////////////////////////////////////////////////////
//
// (C) Copyright Ion Gaztanaga 2005-2008. Distributed under the Boost
// Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
// See http://www.boost.org/libs/interprocess for documentation.
//
//////////////////////////////////////////////////////////////////////////////
#ifndef BOOST_INTERPROCESS_MAPPED_REGION_HPP
#define BOOST_INTERPROCESS_MAPPED_REGION_HPP
#include <boost/interprocess/detail/config_begin.hpp>
#include <boost/interprocess/detail/workaround.hpp>
#include <boost/interprocess/interprocess_fwd.hpp>
#include <boost/interprocess/exceptions.hpp>
#include <boost/interprocess/detail/move.hpp>
#include <boost/interprocess/detail/utilities.hpp>
#include <boost/interprocess/detail/os_file_functions.hpp>
#include <string>
#include <limits>
#if (defined BOOST_INTERPROCESS_WINDOWS)
# include <boost/interprocess/detail/win32_api.hpp>
#else
# ifdef BOOST_HAS_UNISTD_H
# include <fcntl.h>
# include <sys/mman.h> //mmap
# include <unistd.h>
# include <sys/stat.h>
# include <sys/types.h>
# include <sys/shm.h>
# include <cassert>
# else
# error Unknown platform
# endif
#endif //#if (defined BOOST_INTERPROCESS_WINDOWS)
....
In this header boost includes go first followed by standard C++
includes, followed by system includes. (This is taken from a header, but
the same include order principle applies to source files).
hardly a good practice.
Hmm. I agree that it's not an ideal situation, but it seems to me
that it's basically the same as that for any other change in class x
that's not 100% backwards compatible. Perhaps it's just that in my
experience, 100% backwards compatible changes are rare.
At work we use interfaces and Pimpl idiom a lot. In the source control
system there are much more revisions to .cc files than to corresponding
..h files. In other words, there are a lot more changes to implementation
source files than to the interface headers.
Separating interfaces and implementation does require more discipline
and upfront thinking, but it makes code base less entangled and more
flexible. Changes to implementation source files this way only trigger
relinking of the clients (because when a shared library is relinked make
can not know whether its binary interface has actually changed and thus
it has to relink its clients).
In fact, adding new #include prerequisites is a lot *less* onerous
than a non-backwards-compatible API change, because it (new #include)
only requires a mechanical change for each *file* using the API,
whereas the (in my experience far more common) non-backwards-compatible
API change may require non-trivial (sometimes *very* non-trivial)
changes at each *call site*.
True.
The original question, however, was concerned with redundant includes
which trigger recompilation that otherwise would be unnecessary.
A good way to cope with this problem has long been known:
* Make header files self-contained by having them include whatever they
require.
* Don't expose implementation details in header files by separating
interfaces and implementation. It can be done with by utilizing Pimpl
idiom or abstract interfaces and factory functions.
--
Max
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]