Re: Header file question
On Wednesday, 25 March 2015 15:46:43 UTC+2, Joseph Hesse wrote:
The following 3 file program was constructed so I could get advice with
header file inclusion. The program compiles and run fine.
= Funcs.h =============================
#ifndef FUNCS_H
#define FUNCS_H
#include <vector>
double sum(std::vector<double> &vd);
#endif
= Funcs.cpp ===========================
#include "Funcs.h"
double sum(std::vector<double> &vd)
{
double s = 0.0;
for(const double &d : vd)
s += d;
return s;
}
= Test.cpp ============================
#include <iostream>
#include "Funcs.h"
int main()
{
std::vector<double> numbers = {1.5, 2.5, 3.5, 4.5};
std::cout << "The sum is " << sum(numbers) << std::endl;
return 0;
}
=======================================
1. In Funcs.cpp the file Funcs.h was included since it seems like best
practices for an X.cpp to always include an X.h. However one could
argue that someone reading Funcs.cpp would see the use of the type
vector<double> and therefore #include <vector> should also be there,
even though it is redundant.
Well ... technically '#include "something.whatever"' means just that
preprocessor takes a text file nimed "something.whatever" and pastes
its contents to that spot. Meaning of '#include <vector>' is often same
in practice but not by C++ standard! By C++ standard '#include <vector>'
means that the interface of <vector> is included. Standard template
'std::vector', its specialization 'std::vector<bool>' and 'std::begin' and
'std::end' become known for compiler and useful for programmer.
Text file named "vector" isn't actually required to be existent.
If we build our own include files with the same policy as those standard
headers are built then the copy-paste include files become actually
interfaces. So "Funcs.h" is interface file for module 'Funcs'. "Funcs.cpp"
is implementation file for module 'Funcs'. Also it is good policy to
include interface header as first thing to module implementation
header.
Now what becomes '#include <vector>' in "Funcs.h" by that policy? It is
up to you.
1) You may say that '<vector>' will be always guaranteed to be
imported by 'Funcs' and so it is part of it. Then it is part of interface.
2) You may say that 'Funcs' will deal with a container of 'double's named
'Doubles' and 'Doubles' now being 'typedef std::vector<double>' Doubles;'
is implementation detail. Users still have to use 'Doubles' since it may
switch (even depending upon platform) to 'std::unordered_multiset<double>'
or 'boost::container::flat_multiset<double>' in future. Then it isn't part of
interface but there is guaranteed some container of doubles in it.
3) You may say that right now 'Funcs' deals only with vectors of doubles but
is planned to evolve into container-agnostic header-only template module
where 'sum' is something like:
namespace func
{
template<Container>
Container::value_type sum(Container const& container)
{
typedef Container::value_type Element;
Element sum {Element()};
for (Element const &e : container)
{
sum += e;
}
return sum;
}
} // func namespace
On such case you may say that <vector> is not part of interface and the
users should pick only vector of doubles now but may pick any container
themselves in the future.
4) Etc. Basically, you are the architect you tell.
2. Same question for Test.cpp. Should #include <vector> be there since
it already comes from #include Funcs.h?
Same question and same answer. ;-) C++ does not contain real modules.
there were talks to add those to C++17. Since there are also "concepts
lite" and "reflection" in queue it is more likely that there either won't be
standard by 2017 or it won't contain modules.
So right now you have to emulate modules with policies of preprocessor
usage. What interfaces your "module" imports and what of those it
exposes is right now a meta-information that you have to deliver to your
module's users with comments, documentation or other external means.