CvForestTree and CvBoostTree hides virtual functions of the base class CvDTree
When I run the example of tutorial, the clang3.2 give me warning like following.
opencv2/ml/ml.hpp:863:18: note: hidden overloaded virtual function 'CvDTree::train' declared here virtual bool train( CvMLData* trainData, CvDTreeParams params=CvDTreeParams() );
I check the declaration of the header file "ml.hpp"
The derived classes of CvDTree--CvBoostTree and CvForestTree declare an interfaces like this
virtual bool train( CvDTreeTrainData* trainData,
const CvMat* subsample_idx, CvBoost* ensemble );
But the signature of the CvDTree are
virtual bool train( CvDTreeTrainData* trainData, const CvMat* subsampleIdx );
Apparently, this is not override nor overload but hiding, is this the intention of the library?
example :
#include <iostream>
class base
{
public:
virtual void output(int, int, int) { std::cout<<"base output"<<std::endl;}
};
class derived : public base
{
public:
virtual void output(int, int) { std::cout<<"derived output"<<std::endl;} //hide the output of base class
};
int main()
{
derived derive_class_2;
derive_class_2.output(0, 0); //output "derived output"
//derive_class_2.output(0, 0, 0); //compile time error, because the output of derived
//class hide the function of the base class
return 0;
}
if you want to know more details, please check "exceptional c++ item 21", the book show us how to classify override, overload and hide in depth.
nice detective story ;)
somehow all code paths end up either calling
bool CvDTree::do_train( const CvMat* _subsample_idx )
or throw an assert(0)@berak is this the intention of the library?Should I treat this as a bug and report it?
at least it's pretty ugly. all those dead-end unused/redirected virtual functions. looks like
"oh, we don't do it that way any more, but we have to keep the interface"
if you plan a bug report, expect: "Nice Find, please make a pr if you come up with a solution" ;)
@berak so this is some sort of "history mistake"?I have no idea how to fix it because I don't familiar with the SVM of openCV yet.If it really running out of choice, the easiest solution is develop a new class with interfaces pretty close to the old one and mark the old interfaces as "deprecated".
hey, no idea, what's going on behind the scenes there, i'm only guessing.
and now, what's the SVM got to do with it ?