Gary Wessle wrote:
Hi
is it right to have a line like
#include <path/to/header.hfor 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_som elib a_function_that _i_provide();
mystuff.cpp
#include "mystuff.h"
a_type_from_som elib 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_som elib
// 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_som elib;
typedef bool stealth_type;
somelib.h
#include "path/to/somethingelse.h "
a_type_from_som elib a_function_from _somelib();
mystuff.h
#include "path/to/somelib.h"
a_type_from_som elib a_function_that _i_provide();
mystuff.cpp
#include "mystuff.h"
a_type_from_som elib a_function_that _i_provide()
{
return a_function_from _somelib();
}
void another_functio n()
{
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_som elib 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_som elib;
a_type_from_som elib 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_som elib a_function_that _i_provide()
{
return a_function_from _somelib();
}
void another_functio n()
{
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.
