Jim Tester wrote:
Thanks, yes that was a typo. But I did as you've noted add the header to
the file and it works. Thanks.
Another question in regards to headers now. I have a main file called
"includes.h" in which I include all the headers in my project there as such:
include.h
-------------------------------
my.h
another.h
more.h
evenmore.h
-------------------------------
And then I include includes.h to all the other files. Although I thought
this was the best way of going about this, it's apparently not.
So then should I just include the correct header files in any file that
needs them instead of trying to have a "blanket" header file that includes
all the other files?
Please don't top-post, or use common sense in quoting (or trimming of what
you quote). Thanks.
Regarding headers, your approach (with bundling them up in one header) is
valid and used by some organizations especially when headers do not change
much from build to build, which allows them to be precompiled, etc.
However, for the maintainability and readability of any single translation
unit I do prefer to have all headers included in it explicitly, and only
the ones that contain the declarations/definitions of symbols used in that
translation unit. IOW, if I use 'printf', I know I need <cstdio>, and if
I use 'pair' I need <utility> no matter if I have already included <map>
(which might include <utility> in my implementation, for example).
The rule of thumb many folks here subscribe to is simple: in any file you
write which contains externally defined/declared symbols, you need to add
the #include directive for the header that defines/declares that symbol.
It doesn't matter if your file is a C++ source or another header. So, you
may end up including some headers twice in some translation units, or more
times, but that should present no particular problem if the header has so
called "multiple inclusion guards".
HTH
V