So I've built a Queue data sructure(all the needed methods) and I just wanted to know how can I use my Queue objects in different project ?

depens, since everything is relative, but never in my life tried to do above given task, so if u chold help, it would be me not beeing so much noobish :D

Usually, developers will maintain their library (or component) code in a source/header structure. In your case it would be the header files and source for the Queue you have built. Yours may be header-only, but I'll assume that there are also source files.

If your design is proper, you should be able to take these files, include the headers in another project and add the source files to the build for that project and things should 'just work.'

This is a very good exercise to go through as it teaches you the basics of why you want to design an interface to your code and keep the implementation separate. As you try to port this implementation to a new code base keep track of the times when you say "ughh, why do I have to change that", these are good indicators of where a better design will help in the future.

OK, the answer depends on just what it is you need help with, separating your classes, or managing the project. The second would depend on your development environment, but first part is going to be the same in pretty much all cases.

First, create a new file for the class header, and another for the class methods. So, for a class Foo, you would have a header file foo.h:

#ifndef FOO_H
#define FOO_H
#include <string>

class Foo 
{
public:
    Foo();
    void bar();
    std::string baz(int flarp);
    std::string getQuux() {return quux;};
private:
    std::string quux;
};
#endif

and a source file foo.c:

#include <string>
#include "foo.h"

Foo::Foo() 
{
 // ...
}

void Foo::bar() 
{
 // ...
}

std::string Foo::baz(int flarp) 
{
 // ...
} 

The comments and elipses indicate where the body of the methods would go.

Now, you will want to note a few things about these files. First off, the #ifndef/#endif are conditional compilation directives, which in this case say, 'if FOO_H is not defined, compile this, otherwise skip to the #endif'. This specific idiom, of putting such conditionals around the body of a header, is what is know as a inclusion guard, and is used to prevent the compiler from including the same header twice in the same source file.

The other thing you'll see is what isn't there: using namespace std;. With class definitions, and header files in general, you want to avoid the using directive. Instead, I used the scope operator on the references to classes and functions in the std namespace, like so:

std::string
std::cout
std::cin 

etc.

You should always scope namespaces explicitly in a header file, without exceptions.

The other thing missing is the bodies of most of the functions. With the exception of very small methods (like a getter or setter), you will want to put the actual implementation of the methods in the implementation (source) file. You will need to include the header file, and use the scope operator to indicate that the methods belong to the class.

The whole point of this exercise is to allow for separate compilation: you can compile the class to an object file or even a library, and use the header to tell the code which uses the class what is in the object file. You might want to see this post to get a better idea of the purpose for this, but that is in a nutshell how you prepare a class to be used in multiple projects.

Edited 2 Years Ago by Schol-R-LEA

This question has already been answered. Start a new discussion instead.