Gary said:
Hi
is it right to have a line like
#include <path/to/header.h> for a library on my system, in my header
file and use some functions provided by this library in the
implementation file (file.cpp) inside a class with out declaring those
functions in the class declaration in the header file?
thanks
Believe it or not, this can be a complicated subject.
If you need something from the library header in order to write your own
header, then this is typical:
mystuff.h:
#include "path/to/somelib.h"
a_type_from_somelib a_function_that_i_provide();
mystuff.cpp
#include "mystuff.h"
a_type_from_somelib a_function_that_i_provide()
{
return a_function_from_somelib();
}
If you do NOT need something from the library header in order to write
your own header, but you do need something from the library in order to
write your implementations then this is typical:
mystuff.h:
void a_function_that_i_provide();
mystuff.cpp
#include "myclass.h"
#include "path/to/somelib.h"
void a_function_that_i_provide()
{
a_function_from_somelib();
}
And of course, if you don't need the library header at all, then this is
typical:
mystuff.h:
void a_function_that_i_provide();
mystuff.cpp
#include "myclass.h"
void a_function_that_i_provide()
{
}
The difference between the first and the second case is that in the
first case you expose your users to somelib.h, while in the second case
you do not. Mildly prefer not to expose them. Don't prefer it strongly
though. For example, don't go this far:
********* A STEP TOO FAR ********
mystuff.h:
// my_own_type is the same as a_type_from_somelib
// I looked that type up and made my own just to avoid
// including somelib.h
typedef int my_own_type;
my_own_type a_function_that_i_provide();
mystuff.cpp
#include "path/to/somelib.h"
#include "mystuff.h"
my_own_type a_function_that_i_provide()
{
return a_function_from_somelib();
}
********* A STEP TOO FAR ********
If you follow those rules, then you are honoring the informal rule that
all of us (c++ programmers) more or less follow: If I need something
from another header to use the stuff in your header, then include it for
me. If I don't, then don't.
There's a flaw in this approach that you should be aware of. Consider
this possibility.
somethingelse.h
typedef int a_type_from_somelib;
typedef bool stealth_type;
somelib.h
#include "path/to/somethingelse.h"
a_type_from_somelib a_function_from_somelib();
mystuff.h
#include "path/to/somelib.h"
a_type_from_somelib a_function_that_i_provide();
mystuff.cpp
#include "mystuff.h"
a_type_from_somelib a_function_that_i_provide()
{
return a_function_from_somelib();
}
void another_function()
{
stealth_type i_am_a_stealth_dependency;
}
The code in mystuff.cpp has a stealth dependency on somethingelse.h.
stealth_type is available to you in mystuff.cpp, so the program
compiles. It's an accident though: the REASON that stealth_type is
available is that a_type_from_somelib is needed.
The guy who maintaind somelib.h would be perfectly within his (informal)
rights to decide that he no longer needs to include somethingelse.h and
rewrite this way:
somelib.h
typedef int a_type_from_somelib;
a_type_from_somelib a_function_from_somelib();
If he did, mystuff.cpp wouldn't compile anymore because of the stealth
dependency. The proper way to write mystuff.cpp is:
mystuff.cpp
#include "mystuff.h"
#include "path/to/somethingelse.h"
a_type_from_somelib a_function_that_i_provide()
{
return a_function_from_somelib();
}
void another_function()
{
stealth_type i_am_no_longer_stealthed;
}
If you are fastidious enough, then you can avoid this mistake in your
own code.
Unhappily, the people who use your code (include mystuff.h) may not be
so fastidious, and they might build in a stealth dependency on
somethingelse.h. When their code blows up, of course, they will blame you.
