Thread: Template problem

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.

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.