Specialised collections (or not)

[Jaybob66]

I've got myself into a debate in the office about specialised collections, I feel like a lone voice atm so thought i'd throw it in here for feedback.

Our codebase is very large, Its a VS2010 MFC app with 770,000 lines of code and comments according to cloc, and its going to grow for another year or so.

All of our main collections (about 20) are defined as typedef std::vector<MyType> MyTypeVec_t;

As you can see, our "specialised" vectors provide NO specialised members, I think thats bad, but I am alone in that. every time we do anything with these collections we have to do it long arm and it makes me grumble [aloud :)].

I think we should have some specialised members on these types....

 class MyTypeVec_t : public std::vector<MyType>
{
    public:
        MyTypeVec_t AllInRect(rectF rect);
        MyType& TopMostAtPoint(PointF pt);
};

What do you think? how do you treat major collections in your applications?

[MiiNiPaa]

Do not inherit from standard containers. They does not have virtual destructors, so you cannot use them as pointer to base which defeats all need for inheritance.

When design class try to make member functions only those which you cannot make nonmember or it would be perfomance hit. Do not make classes as std::basic_string!

In your case it is better to make those functions as nonmember: MyType& TopMostAtPoint(const MyTypeVec_t& source, PointF pt);

All of our main collections (about 20) are defined as typedef std::vector<MyType> MyTypeVec_t;

It is completely normal.

[doug4]

@OP

Are you saying that there are 20 vectors of the same type (MyType)? Or are there 20 different "MyTypes", each with a vector defined for it? If it's 20 typedefs of the same thing, you only need 1 of them.

If there are 20 vectors of the same thing that are conceptually different and behave differently, then there should be separate classes for those vectors. For instance, if you have a vector of dogs representing animals at the pound and a vector of dogs representing service animals provided to the visually impaired, at the end you simply have a list of dogs. The dog class used for both lists may be completely identical (this is an extremely simplistic example ;) ). But the criteria for manipulating the vectors may be completely different. In this case, two classes should be created: 1 for the collection of dogs at the pound and 1 for the collection of service dogs.

I very seldom #define a STL class instantiation in the global or namespace scope. Frequently I wrap an STL instantiation as a data member of another class. I typedef the STL instantiation at class scope for clarity in the code, and I usually typedef the iterator, too, for use later in the code. (I use lots of maps and lists where iterators come in really handy.)

class MyTypeCollection
{
public:
    ...
private:
    typedef std::vector<MyType>    MyVector;
    typedef MyVector::iterator     MyIterator; 

    MyVector  elements;
};

[Jaybob66]

@doug4
20 different MyTypes, soz for the confusion.

we only use #defines for compile directives, because they cant be examined in the debugger.

MiiniPaa wrote:

Do not inherit from standard containers. They does not have virtual destructors

Yes, thats fine for us, we have no intention of deriving our collections further. Our MyTypes are distinct items from an external machine interface.

Also, not having a virtual destructor isn't a very good reason for not deriving from a class, Its just a good reason to not virtualise it.