Templated typedef?

You cannot use a "templated typedef", but you can use a convenience class/struct with an inner type.

You cannot use a "templated typedef", but you can use a convenience class/struct with an inner type: template struct TypeHelper{ typedef std::vector > Vector; }; and then use in your code TypeHelper::Vector v; TypeHelper::Vector::iterator it; And something similar for the map: template struct MapHelper{ typedef std::map > Map; }; EDIT - @Vijay: I don't know if there's another possible workaround, that's how I would do it; a macro might give you a more compact notation, but personally I wouldn't like it: #define GCVECTOR(T) std::vector > EDIT - @chmike: Please note that the TypeHelper solution does not require you to redefine constructors!

– Warrior Mar 16 '09 at 9:43 Yeap, there is. Inheritance is much neater is this very case. – sharptooth Mar 16 '09 at 9:49 @sharptooth: it's true that inheritance in this case gives you the best notation and avoids the use of a macro, but its usage is debatable, as pointed out in the comments to your answer.

– Paolo Tedesco Mar 16 '09 at 9:56 I'm patiently waiting for any proof of potential problems. – sharptooth Mar 16 '09 at 10:02 1 You could add in your answer that template typedefs (aka template aliases) will be included in C++0x (however, it's not supported by gcc yet) open-std.Org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf. – Luc Touraille Mar 16 '09 at 16:02.

You can publicly inherit: template class gc_vector : public std::vector { public: // You'll have to redeclare all std::vector's constructors here so that // they just pass arguments to corresponding constructors of std::vector }; This solves your problem completely. The derived type can be used everywhere where the base type can be used, and there's no implementation overhead with any decent compiler. The fact that std::vector has non-virtual destructor might lead to undefined behaviour according to C++ standard if you ever try to delete a derived class variable through a pointer to base class variable.In real world this shouldn't matter in this particular case - the derived class has nothing new added compared to the base class and therefore the destructor for the derived class just calls the destructor for the base class.

Proceed with paranoia, port carefully anyway. If you never allocate this class variables on heap (and it's typical to allocate vector variables on stack and as members of other classes) the non-virtual destructor problem doesn't affect you.

There is the problem that vectors are not designed to be derived from, as they lack a virtual destructor. – anon Mar 16 '09 at 9:27 True, but it doesn't matter in this particular case, since the derived type has exactly the same set of meber variables as the base type. – sharptooth Mar 16 '09 at 9:33 It matters if he deletes a pointer to a base that points to a derived as he is then off in undefined behaviour land.

– anon Mar 16 '09 at 9:36 1 Nope, it doesn't matter in this case. The derived has no new data members compared to the base, so there's no difference between delete for Base* and Derived*. The derived constructor just calls the base constructor anyway.

– sharptooth Mar 16 '09 at 9:42 hi sharptooth, what if he creates some memory in the derived constructor and deletes a pointer to a base that points to a derived class. Memory leak isnt it. I think, your solution fits perfectly for the current question, but its not robust.

– Warrior Mar 16 '09 at 9:55.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.