By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,569 Members | 1,422 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,569 IT Pros & Developers. It's quick & easy.

including a lib header file

P: n/a
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
Jul 22 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Gary Wessle wrote:
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?
If it works for you, what is your conccern?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jul 22 '06 #2

P: n/a
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_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.
Jul 22 '06 #3

P: n/a
Howard Gardner <hg******@rawbw.comwrites:
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_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.

thank you

you did not explicitly mention whether I can place
a_function_from_somelib in the public scope of a
a_class_that_i_provide but I take it that you implied it. if so, then
why I getting this error which appear to be a linker error?

**************** start error ****************
fred@debian:~/myPrograms/common$ make
g++ -c -o read_data.o read_data.cpp
g++ -c -o read_data_test.o read_data_test.cpp
g++ -Wall -o proj read_data.o read_data_test.o -lgsl
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dsdot'
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dswap'
.... a long list of them
**************** end error ****************
for this project

**************** start read_data.h ****************
#ifndef READ_DATA_H
#define READ_DATA_H
#include <string>
#include <cstdio>
#include <gsl/gsl_matrix.h>
class read_data
{
int nRows, nCol;
std::string file_name;
void set_No_of_Rows_Cols();
gsl_matrix * m; // from gsl_matrix.h
void matrix_the_file();

public:
read_data(std::string const& fileName);
~read_data();

};
#endif
**************** end read_data.h ****************
**************** start read_data.cpp ****************
#include <string>
#include <fstream>
#include <iostream>
#include <sstream>
#include <cstdlib>
#include <cstdio>
#include "read_data.h"
#include <gsl/gsl_matrix.h>

using namespace std;

read_data::read_data( string const& fileName )
: file_name( fileName ), nCol(0), nRows(1) {
set_No_of_Rows_Cols();
matrix_the_file();
}

read_data::~read_data() {}

void read_data::matrix_the_file(){
// allocate memory for the matrix
// needs to be freed later using
// void gsl_matrix_free (gsl_matrix * m)
m = gsl_matrix_alloc (nRows, nCol);
FILE * f = fopen(file_name.c_str(), "rb");
gsl_matrix_fscanf (f, m);
fclose(f);

}

void read_data::set_No_of_Rows_Cols() {
ifstream in(file_name.c_str());
string line;
getline(in, line);
stringstream input( line.c_str() );

string word;
while(input >word)
nCol++; // init'd by constructor

while (getline(in, line))
nRows++; // init'd by constructor
}

/*
std::string command = "wc -l";
std::system( ( command + " " + file_name ).c_str() );
}
*/

**************** end read_data.cpp ****************
**************** start read_data_test.cpp ****************
#include <fstream>
#include <iostream>
#include <string>
#include "read_data.h"

using namespace std;

int main() {
string f = "../../data/ZB/Jun06/20060405";
read_data data1( f ); // space delimited
}
**************** end read_data_test.cpp ****************
**************** start makefile ****************
OBJS := $(patsubst %.cpp,%.o,$(wildcard *.cpp))
COMP = g++

proj: $(OBJS)
$(COMP) -Wall -o proj $(OBJS) -lgsl

#-Wall turns on all warnings
**************** end makefile ****************
Jul 22 '06 #4

P: n/a
Gary Wessle wrote:
you did not explicitly mention whether I can place
a_function_from_somelib in the public scope of a
a_class_that_i_provide but I take it that you implied it. if so, then
why I getting this error which appear to be a linker error?

**************** start error ****************
fred@debian:~/myPrograms/common$ make
g++ -c -o read_data.o read_data.cpp
g++ -c -o read_data_test.o read_data_test.cpp
g++ -Wall -o proj read_data.o read_data_test.o -lgsl
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dsdot'
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dswap'
... a long list of them
**************** end error ****************
[snip]

It is a linker error, and it appears that you are not linking all the
libraries you need to build this program. However, this is not a C++
*language* question (the topic of this forum). You should ask on
newsgroup that deals with your development platform or the library in
question. See this FAQ for what is on-topic here and for some ideas of
where else you could ask:

http://parashift.com/c++-faq-lite/ho...t.html#faq-5.9

Cheers! --M

Jul 22 '06 #5

P: n/a
Gary Wessle wrote:
>
thank you

you did not explicitly mention whether I can place
a_function_from_somelib in the public scope of a
a_class_that_i_provide but I take it that you implied it. if so, then
why I getting this error which appear to be a linker error?

**************** start error ****************
fred@debian:~/myPrograms/common$ make
g++ -c -o read_data.o read_data.cpp
g++ -c -o read_data_test.o read_data_test.cpp
g++ -Wall -o proj read_data.o read_data_test.o -lgsl
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dsdot'
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dswap'
... a long list of them
**************** end error ****************
I don't use g++, so I don't know the command line syntax. I also don't
use the gsl library, so I don't know how it's structured. What I am
going to say next is, therefore, a guess.

cblas_dsdot, cblas_dswap, and the rest of the things on that list are
used from the library gsl, but they aren't actually in gsl. They are in
another library (or an object file). You need to find that library (or
object file) and tell your compiler about it. Once you've done that, you
may have new link errors that send you in search of more libraries files.

There's an excellent chance that the documentation or the faq for the
gsl library will tell you which other libraries you must link to.

Jul 22 '06 #6

P: n/a
mlimber wrote:
Gary Wessle wrote:
It is a linker error, and it appears that you are not linking all the
libraries you need to build this program. However, this is not a C++
*language* question (the topic of this forum). You should ask on
newsgroup that deals with your development platform or the library in
question. See this FAQ for what is on-topic here and for some ideas of
where else you could ask:
He's struggling through the standard C++ interface to a library:
includes and links. It *is* a c++ language issue.

The answer is the same for every library/compiler combination in the
known universe: "The linker is missing library files. RTF compiler M to
learn what library files are and how to link them, then RTF library M to
learn which files you need for this library." Even if he were to find a
group dedicated to using this library with this compiler, the answer is
still "RTFMs."
Jul 22 '06 #7

P: n/a
Howard Gardner <hg******@rawbw.comwrites:
Gary Wessle wrote:
thank you
you did not explicitly mention whether I can place
a_function_from_somelib in the public scope of a
a_class_that_i_provide but I take it that you implied it. if so, then
why I getting this error which appear to be a linker error?
**************** start error ****************
fred@debian:~/myPrograms/common$ make
g++ -c -o read_data.o read_data.cpp
g++ -c -o read_data_test.o read_data_test.cpp
g++ -Wall -o proj read_data.o read_data_test.o -lgsl
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so: undefined
reference to `cblas_dsdot'
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../lib/libgsl.so:
undefined
reference to `cblas_dswap'
... a long list of them
**************** end error ****************

I don't use g++, so I don't know the command line syntax. I also don't
use the gsl library, so I don't know how it's structured. What I am
going to say next is, therefore, a guess.

cblas_dsdot, cblas_dswap, and the rest of the things on that list are
used from the library gsl, but they aren't actually in gsl. They are
in another library (or an object file). You need to find that library
(or object file) and tell your compiler about it. Once you've done
that, you may have new link errors that send you in search of more
libraries files.

There's an excellent chance that the documentation or the faq for the
gsl library will tell you which other libraries you must link to.
indeed, you are right, after I did RTM, I fixed my makefile, now it
looks like this
************************************************** **************
OBJS := $(patsubst %.cpp,%.o,$(wildcard *.cpp))
COMP = g++

#### compiler section ####
proj: $(OBJS)
$(COMP) -Wall -I/usr/include -c $(OBJS)
#-Wall turns on all warnings

#### linker section ####
proj: $(OBJS)
$(COMP) -L/usr/local/lib $(OBJS) -lgsl -lgslcblas -lm

clean:
rm -rf *.o a.out
************************************************** **************
may what a lesson I will NEVER forget, the problem was that even that
I was RTM, I did not understand all what I was reading.

now I have a little problem with the following warning that I am
working on. help is welcome.

:~/myPrograms/common$ make
makefile:13: warning: overriding commands for target `proj'
makefile:6: warning: ignoring old commands for target `proj'
g++ -c -o read_data.o read_data.cpp
g++ -L/usr/local/lib read_data.o read_data_test.o -lgsl -lgslcblas -lm
Jul 22 '06 #8

P: n/a

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:2o******************************@comcast.com. ..
Gary Wessle wrote:
>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?

If it works for you, what is your conccern?
Sounds like he's asking for advice as to best
practices but he doesn't really give enough
information. For example, whether he's using
functions in the library or objects...
Jul 23 '06 #9

P: n/a
Gary Wessle wrote:
indeed, you are right, after I did RTM, I fixed my makefile, now it
looks like this
************************************************** **************
OBJS := $(patsubst %.cpp,%.o,$(wildcard *.cpp))
COMP = g++

#### compiler section ####
proj: $(OBJS)
$(COMP) -Wall -I/usr/include -c $(OBJS)
#-Wall turns on all warnings

#### linker section ####
proj: $(OBJS)
$(COMP) -L/usr/local/lib $(OBJS) -lgsl -lgslcblas -lm

clean:
rm -rf *.o a.out
************************************************** **************
may what a lesson I will NEVER forget, the problem was that even that
I was RTM, I did not understand all what I was reading.

now I have a little problem with the following warning that I am
working on. help is welcome.

:~/myPrograms/common$ make
makefile:13: warning: overriding commands for target `proj'
makefile:6: warning: ignoring old commands for target `proj'
g++ -c -o read_data.o read_data.cpp
g++ -L/usr/local/lib read_data.o read_data_test.o -lgsl -lgslcblas -lm
You've RTMed; now RTFAQ to see what this group is about:
<http://parashift.com/c++-faq-lite/how-to-post.html#faq-5.9>. You'll
find that makefile questions are also off-topic here because they
pertain only to a particular build environment, but I'll give you a
hint: you have two "proj:"'s in your makefile. You'll want to ask in,
say, a UNIX development newsgroup if you need further help on this
issue.

Cheers! --M

Jul 23 '06 #10

P: n/a
Howard Gardner wrote:
mlimber wrote:
Gary Wessle wrote:
It is a linker error, and it appears that you are not linking all the
libraries you need to build this program. However, this is not a C++
*language* question (the topic of this forum). You should ask on
newsgroup that deals with your development platform or the library in
question. See this FAQ for what is on-topic here and for some ideas of
where else you could ask:

He's struggling through the standard C++ interface to a library:
includes and links. It *is* a c++ language issue.
I grant that there is more gray area than FAQ 5.9 allows when read
strictly (and you'll see that I respond to questions here accordingly),
but ISTM that he's dealing with how to use a third-party library in a
particular development environment. That's no more a C++ language
question than, say, how to statically link an MFC app on Windows.
The answer is the same for every library/compiler combination in the
known universe: "The linker is missing library files. RTF compiler M to
learn what library files are and how to link them, then RTF library M to
learn which files you need for this library." Even if he were to find a
group dedicated to using this library with this compiler, the answer is
still "RTFMs."
The OP should ask his question in a newsgroup or other forum dedicated
either to his development environment (UNIX and/or gcc) or to the
third-party library in question to get that answer (or a more helpful
one, such as "Add -lgslcblas -lm to your link line because ..."). The
fact that the minimal answer is always RTM doesn't mean that this is
the appropriate place for him to receive that answer, and the OP's
follow-up question to your answer seems to illustrate that answering
non-topical questions encourages more of the same.

Cheers! --M

Jul 23 '06 #11

P: n/a
mlimber wrote:
Howard Gardner wrote:
>mlimber wrote:
>>Gary Wessle wrote:
It is a linker error, and it appears that you are not linking all the
libraries you need to build this program. However, this is not a C++
*language* question (the topic of this forum). You should ask on
newsgroup that deals with your development platform or the library in
question. See this FAQ for what is on-topic here and for some ideas of
where else you could ask:
He's struggling through the standard C++ interface to a library:
includes and links. It *is* a c++ language issue.

I grant that there is more gray area than FAQ 5.9 allows when read
strictly (and you'll see that I respond to questions here accordingly),
but ISTM that he's dealing with how to use a third-party library in a
particular development environment. That's no more a C++ language
question than, say, how to statically link an MFC app on Windows.
>The answer is the same for every library/compiler combination in the
known universe: "The linker is missing library files. RTF compiler M to
learn what library files are and how to link them, then RTF library M to
learn which files you need for this library." Even if he were to find a
group dedicated to using this library with this compiler, the answer is
still "RTFMs."

The OP should ask his question in a newsgroup or other forum dedicated
either to his development environment (UNIX and/or gcc) or to the
third-party library in question to get that answer (or a more helpful
one, such as "Add -lgslcblas -lm to your link line because ..."). The
fact that the minimal answer is always RTM doesn't mean that this is
the appropriate place for him to receive that answer, and the OP's
follow-up question to your answer seems to illustrate that answering
non-topical questions encourages more of the same.

Cheers! --M
I answered the on topic question. I ignored the off topic. See how that
works?
Jul 23 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.