Question: I encounter many times with code where std::vector::clear() of class member of type std::vector is called in constructor and destructor. 

I don't see why it's required:

1. **constructor** - the class member of type std::vector is empty by default, so no need to call clear().
2. **destructor** - the class member of type std::vector will be destroyed as part of standard destruction of object contnaining it. As part of vector destruction all **value objects** containied in it will be destroyed (if it heap allocated pointers to memory, they should be deleted "manually"), so again no need to call clear().

Do I miss something?

Answer: 
No, you're not missing anything. I suspect this is (harmless) voodoo programming, sort of like setting a pointer to null after freeing it, or randomly calling repaint/revalidate in GUI code. The programmer remembers that it helped with some sort of bug in the past and now adds it unnecessarily "just in case". Who knows, maybe it'll help. Voodoo.
Despite what what said so far, there's at least one scenario when an explicit call to `clear` in the destructor might be necessary. 

Imagine the situation when the object being destroyed has several member subobjects, which require some specific order of destruction, i.e. the subobjects somehow depend on each other, and an incorrect order of their destruction will lead to undesirable results. As you probably know, the order of member subobject destruction (as well as member initialization) is determined by the order of members' declararion in class definition. So, one way to achive the proper order of destruction is to arrange the member declarations accordingly. However, firstly, this is not a very good solution maintenance-wise. Secondly, the desired order of destruction might depend on some run-time conditions. Thirdly, the desired order of destruction might contradict the desired oreder of initialization. This all means that it might not be possible (or wise) to command the proper order of destruction by re-arranging the declarations. 

A reasonable approach in this case might be to clean-up some critical member subobjects manually, by calling their `clean` methods or such, until the destruction order dependency "disappears". I would guess, that maybe the code that you saw was trying to resolve to ordering problem by calling `clean` on a strategically selected `vector` subobject.

As for calling `clean` in constructor... I have no idea why anyone would do something like that.