including a lib header file

Discussion in 'C++' started by Gary Wessle, Jul 22, 2006.

  1. Gary Wessle

    Gary Wessle Guest

    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
    Gary Wessle, Jul 22, 2006
    #1
    1. Advertising

  2. 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
    Victor Bazarov, Jul 22, 2006
    #2
    1. Advertising

  3. 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.
    Howard Gardner, Jul 22, 2006
    #3
  4. Gary Wessle

    Gary Wessle Guest

    Howard Gardner <> 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 ****************
    Gary Wessle, Jul 22, 2006
    #4
  5. Gary Wessle

    mlimber Guest

    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/how-to-post.html#faq-5.9

    Cheers! --M
    mlimber, Jul 22, 2006
    #5
  6. 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.
    Howard Gardner, Jul 22, 2006
    #6
  7. 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."
    Howard Gardner, Jul 22, 2006
    #7
  8. Gary Wessle

    Gary Wessle Guest

    Howard Gardner <> 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
    Gary Wessle, Jul 22, 2006
    #8
  9. Gary Wessle

    Duane Hebert Guest

    "Victor Bazarov" <> wrote in message
    news:...
    > 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...
    Duane Hebert, Jul 22, 2006
    #9
  10. Gary Wessle

    mlimber Guest

    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
    mlimber, Jul 23, 2006
    #10
  11. Gary Wessle

    mlimber Guest

    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
    mlimber, Jul 23, 2006
    #11
  12. 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?
    Howard Gardner, Jul 23, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kpoan
    Replies:
    0
    Views:
    387
    kpoan
    Aug 15, 2006
  2. Prajakta Jitkar
    Replies:
    1
    Views:
    1,256
    Gordon Beaton
    Feb 27, 2007
  3. hankssong
    Replies:
    9
    Views:
    533
  4. 'Mani
    Replies:
    4
    Views:
    485
    gangs
    Apr 3, 2006
  5. mlt
    Replies:
    2
    Views:
    831
    Jean-Marc Bourguet
    Jan 31, 2009
Loading...

Share This Page