Right, so we should all basically agree that deriving from standard containers (std::vector, std::map, et. al.) is a bad idea. The classes aren't designed for it; the lack of virtual functions and virtual destructors makes polymorphism a veritable minefield (if not outright impossible); and so on.
Now here's my question - I need some ammunition for a debate over a few different options.
Option #1, the current way
typedef std::map<foo, bar, std::less<foo>, special_allocator<std::pair<foo, bar>, memory_annotations> > FooBarMapT;
This works great, uses the custom allocator as required, and so on. The only real disadvantage is it is a bit verbose, and you have to specify the types twice (one for the container, one for the allocator).
Option #2, my preferred alternative
#define SPECIALMAP(foo, bar, memory_annotations) std::map<foo, bar, std::less<foo>, special_allocator<std::pair<foo, bar>, memory_annotations> >
This cuts out the duplication, makes the declarations a bit shorter, and generally works as nicely as Option #1. The only problem is it introduces an unusual syntax (SPECIALMAP(foo, bar, quux) instead of std::map<foo, bar ...>
Option #3, which I am convinced is a veritable lie from the bowels of Satan himself
template specialmap<class foo, class bar, quux memory_annotations> : public std::map<foo, bar, std::less<foo>, special_allocator<std::pair<foo, bar>, memory_annotations> > FooBarMapT;
This just
feels evil to me. Yes, it preserves the original map<foo, bar ...> syntax, but... just... eew. Inheritance for no good reason. Deriving from an STL container class. Polymorphism is now verboten or we'll end up with a lot of really slimy bugs.
Now, I'm not actually sure if I'm right about this. It seems, instinctively, that option #3 is just wrong. But I can't prove it. If I'm correct, I need some kind of thorough explanation as to
why it's a bad idea, and if I'm wrong, then I need to know that, too [smile]
So... break out your copy of the C++ standard and go to town. Enlighten us.