Quote:Original post by nlbs
In my case I dont need anything special at the time of destruction. so if it clls the STL::map's destructor its OK for me.
I'd be glad If I can see some other problemstoo if exists.
and If I dont need something special job on destructor e.g. If I dont need a custom destructor for my subclass isn't it ok to inherit from a Class that doesn't have a virtual destructor ??
One thing I should mention that My subClass doesn't have any member variable.
*** Source Snippet Removed ***
So is there any such problem that might cause malfunctioning ??
Yes, the problem is that you're screwing up the design of std::map.
None of the member functions you have 'added on' need to exist at all, and none of them need to be member functions. Why aren't you implementing your algorithms as taking 2 iterators?
Why is there a get() and set() that's virtual? That's silly, as std::map already provides an efficient way of doing this, without virtual functions.
exists() is just map.find(key) != map.end(). Not sure why you needed to make a new type of map that's incompatible with std::map to add this functionality.
Note that you can't assign a std::map to your new kind of map. You also can't pass a std::map to a function that takes a paramsMapCore, even though everything a function would want to do to your map they can also do to a std::map.
You can't call any of the other constructors that std::map provides, so you're stripping away lots of functionality that keeps map efficient. Why???
search() is bad. There's already find(). No reason to rename this stuff, it's conventional and standard, and lots of code already works with std::map.
removeAll() is bad for the same reason search() is. There's already clear().
remove() is bad. There is already erase(). Remove and erase have different conventional meanings in the standard library. Don't blur the line because you are used to a different naming convention.
I have no idea what each() could possibly do, and why it would return an iterator.
In short, don't inherit from standard containers. There's nothing you could add that *needs* access to the internals, and inheriting from it doesn't give you access to the internals, anyway.