Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > including a lib header file

Reply
Thread Tools

including a lib header file

 
 
Gary Wessle
Guest
Posts: n/a
 
      07-22-2006
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
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      07-22-2006
Gary Wessle wrote:
> 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?


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


 
Reply With Quote
 
 
 
 
Howard Gardner
Guest
Posts: n/a
 
      07-22-2006
Gary Wessle wrote:
> 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.
 
Reply With Quote
 
Gary Wessle
Guest
Posts: n/a
 
      07-22-2006
Howard Gardner <(E-Mail Removed)> writes:

> Gary Wessle wrote:
> > 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.



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 ****************


 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      07-22-2006
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

 
Reply With Quote
 
Howard Gardner
Guest
Posts: n/a
 
      07-22-2006
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.

 
Reply With Quote
 
Howard Gardner
Guest
Posts: n/a
 
      07-22-2006
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."
 
Reply With Quote
 
Gary Wessle
Guest
Posts: n/a
 
      07-22-2006
Howard Gardner <(E-Mail Removed)> writes:

> 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
 
Reply With Quote
 
Duane Hebert
Guest
Posts: n/a
 
      07-22-2006

"Victor Bazarov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Gary Wessle wrote:
>> 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?

>
> 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...


 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      07-23-2006
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Header files with "header.h" or <header.h> ?? mlt C++ 2 01-31-2009 02:54 PM
Help regarding including a .lib file in Java Project using JNI Prajakta Jitkar Java 1 02-27-2007 01:47 PM
how can I find the exact header file including a struct variable? eg. DIR? hankssong C Programming 9 12-03-2006 07:37 AM
error while including the header file javax.xml.parsers.*.. kpoan Java 0 08-15-2006 03:35 AM
Difference between including a header file in .h and .cpp 'Mani C++ 4 04-03-2006 08:10 AM



Advertisments