Template problem

I'm back

Here is my Set class:

Code:

template <class T>
class Set{
	private:
		T *arr;
		int size;
		int num;
	public:
		void insert(T);
		bool contains(T);
		void print(void);
		void sort(void);
		Set findIntersect(Set<T>*);
		//Set findUnion(Set*);
		Set(int);
		~Set();
};

I am trying to implement the findIntersect function (and findUnion for that matter) which takes a Set object created by:

Code:

Set<int> *s2 = new Set<int>(5);

In the main file, and compares THIS set to the one in given as an argument.

The problem is, I am getting an error and probably is a small syntax issue (first time working with templates)

Code:

template <class T>
Set Set<T>::findIntersect(Set<T> *s2){
	return s2;
}

As you can see ATM the function does nothing, but I am just trying to get it working first.

If I change the return type from Set to void, and just print something, it works, so I am guessing it has to do with that.

Error(s) given by VS2008:
Error 1 error C2955: 'Set' : use of class template requires template argument list

Error 2 error C2244: 'Set<T>::findIntersect' : unable to match function definition to an existing declaration

Thanks

What kind of Set do you want to return? You should return a Set<T>.

The error is simple: s2 is a Set pointer, but you want to return a Set object.

I would propose that findIntersect be a member function with this signature:

Code:

Set<T> findIntersect(const Set<T>&) const;

or a free function with this signature:

Code:

Set<T> findIntersect(const Set<T>&, const Set<T>&);

The problem is that it appears that your internal array is not necessarily sorted (otherwise the sort member function would be redundant), so contains() cannot do binary search, and you actually need to sort the internal arrays in order to implement a fast algorithm for findIntersect, but sort clearly should be a non-const member function. On the other hand, although you can directly sort the internal array if findIntersect is a member function, this is a violation of const-correctness (the observable, logical, state of the object changes), even though it probably will not be detected by the compiler.

Note that std::set is typically implemented using a balanced binary tree.

EDIT:
Oh yes, but tabstop's observation is more pertinent.

I wanted to return my definition of a Set

I did try Set<T> before I posted this, and it gives me 1 error:

error C2664: 'Set<T>::Set(int)' : cannot convert parameter 1 from 'Set<T> *' to 'int'

*To laserlight*

I just wrote a bubble sort and call it at the end of my insert because I didn't want to actually insert them in order, so technically it is sorted

And just for clarification, I am referring to set theory ideas of intersections and unions.

Well, that's an error from the constructor, not this function. You're apparently trying to pass a pointer to a Set into your constructor, but your constructor only takes an integer. Since I can't see any relevant code, I have no idea what you wanted to do here.

Eh I figured it out, just changed return type to Set<T>*

Originally Posted by chinesepirate

Eh I figured it out, just changed return type to Set<T>*

Why do you want to use a pointer to a Set<T> as a parameter and then return a pointer to a Set<T>? In fact, what are you going to return? You cannot return a pointer to a local variable, so you will have to return a pointer to a dynamically allocated Set<T>, but that means that the caller has to manage memory, thus defeating one of the advantages of RAII with objects. Also, does your code handle a null pointer argument correctly?

If you pass by const reference as in my suggested function signatures, and then return by value, you will not have these problems. You may want to change the return by value into an out parameter (e.g., one that takes the resulting Set<T> by reference) to avoid extra copying, but this may not even matter at all due to named return value optimisation.

I just wrote a bubble sort

There's another error ...

Originally Posted by laserlight

If you pass by const reference as in my suggested function signatures, and then return by value, you will not have these problems. You may want to change the return by value into an out parameter (e.g., one that takes the resulting Set<T> by reference) to avoid extra copying, but this may not even matter at all due to named return value optimisation.

And also, consider a completely different interface for these operations. What about an "intersection iterator" and "union iterator" concept which when constructed from two sets produces an iterator which iterates, correspondingly, over the items only in both sets, or in items from either set?

Typically the "real work" of using any container is iterating over it, so conceptualizing set operations in terms of iterators instead of operations on sets might be useful -- it would also cut down on copying and memory usage.