views:

122

answers:

2

I am trying to declare a private Data Structure such as the Vector in my C++ header file which I want to eventually use within the method implementation of my .cpp.

An example would be my header "SomeClass.h" where I have:

class SomeClass
{
  private:
  Vector<T> myVector;
  public:
  void AddTtoMyVector(T add);
}

And in my .cpp which is "SomeClass.cpp", I have the following:

#include "SomeClass.h"

SomeClass::AddTtoMyVector(T add)
{
     myVector.Push_back(add);
}

Would the syntax here work? Or is there a different way of declaring and populating such structures?

+1  A: 

Be sure to specify that you're using STL's vector, using either

std::vector<T> myVector;

or

using std::vector;

Also, if T is a generic type, you want to make the whole class templated:

#include <vector>

using std::vector;

template< typename T >
class SomeClass
{
  private:
  vector<T> myVector;
  public:
  void AddTtoMyVector(T add) {myVector.push_back( add );}
}
Artem
Thanks Artem. So speaking out of sheer C++ ignorance, is it possible for just the declarations to be in the .h and the implementations to be in the .cpp? I am drawing a parallel with C# where we have the function signatures in an Interface and the declarations in a class that implements the interface.
sc_ray
Yep, the implementation can be moved to the .cpp file, just like you wrote in your original post (although a common practice is to keep one-liners in the .h file; compilers will often inline such function).
Artem
Yes, that is the typical way of doing things. There are situations where the implementation has to be in the header [specifically, template code and inline functions], but in general that is not true.
Dennis Zickefoose
Thanks Artem. Another question I have is why do we need to specify 'using std::vector'? Doesn't the inclusion of the <vector> tell the compiler, that the STL vector is being used?
sc_ray
Look up namespaces, and how they are used. The full name is `std::vector`, so `vector` means nothing to the compiler without some hint from you as to what you mean.
Dennis Zickefoose
The #inclusion of <vector> defines the class, but the definition resides inside namespace std. This means that anything outside std has to refer to the class as std::vector.You can experiment with namespaces yourself. Trying placing your class inside a namespace, like this:namespace MySpace{ class SomeClass{ ... }; }You will then notice that in your main(), you have to refer to it as MySpace::SomeClass, not SomeClass.
Artem
That explains it. Thanks!
sc_ray
+1  A: 

Following on to Artem's answer, it should be mentioned that although the standard practice for normal C++ classes is to place the declarations in the .h file and the implementations in a coresponding .cpp file, this typically applies only to non-template classes. If you're writing a template class, the entire implementation is usually placed in the same .h file that defines the template interface. There are a number of reasons for doing this and if you're planning on developing a template, I'd suggest investigating this issue a bit further right up front. It'll likely save you some time down the road.

Rakis
Thanks Rakis. Can you point out some of the reasons why the Template class implementations are in the same file as the .h?The template class may be a class with moderate to high complexity and from my experience with other object-oriented languages such as C#, mixing definition with implementation is not such a good idea most of the times.
sc_ray
Templates are just that: templates. The compiler creates entirely new code on demand based on that template. But to do that, it needs access to the entire code for the template, not just the function names. You can still separate out the implementation, often via a #include "blah.cpp" at the bottom of "blah.h".
Dennis Zickefoose
Stroustroup's C++ book (an extremely recommended read) covers the basic issues involved. A web search would also turn up numerous good sources of information as well, I'm sure. Essentially though, it's more of a practical issue of compiler capability and project organization than it is a software design issue. There are a number of approaches, like the one suggested by Dennis, but ultimately it's a matter of style once the compiler capabilities are accounted for.
Rakis