News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

how to remove those compiler warnings

Started by ollydbg, June 04, 2012, 05:31:01 PM

Previous topic - Next topic

ollydbg

include\editorbase.h:36:22: warning: 'virtual void EditorBase::operator=(const EditorBase&)' was hidden [-Woverloaded-virtual]
include\cbeditor.h:70:22: warning:   by 'virtual void cbEditor::operator=(const cbEditor&)' [-Woverloaded-virtual]


I see a lot of such warnings, can we remove them?

Thanks.

MinGW GCC 4.6.3.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

There is no point in operator= being virtual. You can try to remove the virtuals and see what happens :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

MortenMacFly

Quote from: oBFusCATed on June 04, 2012, 06:26:48 PM
There is no point in operator= being virtual. You can try to remove the virtuals and see what happens :)
Why not? If you specialise EditorBase you should ensure also to specialise this operator, don't you?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

jarod42

class DerivedClass : public BaseClass
{
using BaseClass::hiddenFunction;

// other stuff.
};

should remove the warnings.

but I agree that
DerivedClass::operator =(const BaseClass&) is strange

oBFusCATed

Quote from: MortenMacFly on June 04, 2012, 08:24:05 PM
Why not? If you specialise EditorBase you should ensure also to specialise this operator, don't you?
It is quite more complex.
Here is a thorough explanation: http://icu-project.org/docs/papers/cpp_report/the_assignment_operator_revisited.html (scroll to the virtual assignment).

Quote
Remember clone()? This is the polymorphic copy constructor. If you need polymorphic copy on a group of related classes, you define a virtual function called clone() and every class in the tree overrides it to call his own copy constructor. You can't just call X's copy constructor for the same reason you can't just call X's assignment operator.

And this is an explanation for the warning: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9
It happens because the compiler always generates Derived& operator=(Derived &p) no matter if there is Base& operator=(Base &p) (virtual or not).

p.s. I suppose the best we could do is to make operator= an unimplemented private function.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

oBFusCATed

Quote from: oBFusCATed on June 04, 2012, 10:58:03 PM
p.s. I suppose the best we could do is to make operator= an unimplemented private function.
Turns out that the script bindings are using the operator=, but the versions in EditorBase and cbEditor both throw an exception,
so the second best thing is to remove the virtual keyword in their declarations.

EditorBase:
virtual void operator=(const EditorBase& /*rhs*/){ cbThrow(_T("Can't assign an EditorBase* !!!")); }
cbEditor:
virtual void operator=(const cbEditor& /*rhs*/){ cbThrow(_T("Can't assign an cbEditor* !!!")); }

No inheritance is used here...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

Quote from: oBFusCATed on June 05, 2012, 10:23:44 AM
Quote from: oBFusCATed on June 04, 2012, 10:58:03 PM
p.s. I suppose the best we could do is to make operator= an unimplemented private function.
Turns out that the script bindings are using the operator=, but the versions in EditorBase and cbEditor both throw an exception,
so the second best thing is to remove the virtual keyword in their declarations.

EditorBase:
virtual void operator=(const EditorBase& /*rhs*/){ cbThrow(_T("Can't assign an EditorBase* !!!")); }
cbEditor:
virtual void operator=(const cbEditor& /*rhs*/){ cbThrow(_T("Can't assign an cbEditor* !!!")); }

No inheritance is used here...

Ok, remove the "virtual" keyword, then there is not such warning now.

I see another kind of warning:
Quote
include\cbplugin.h:169:22: warning: 'virtual bool cbPlugin::BuildToolBar(wxToolBar*, int&)' was hidden [-Woverloaded-virtual]
include\cbplugin.h:408:22: warning:   by 'virtual bool cbDebuggerPlugin::BuildToolBar(wxToolBar*)' [-Woverloaded-virtual]

Here:in cbPlugin:
        virtual bool BuildToolBar(wxToolBar* toolBar) = 0;
        virtual bool BuildToolBar(wxToolBar* toolBar, int &priority) { priority = 50; return BuildToolBar(toolBar); }


and in derived class:

virtual bool BuildToolBar(wxToolBar* toolBar);
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

This one should be fixed using "using bla bla".
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ptDev

Quote from: ollydbg on June 07, 2012, 03:47:32 AM
I see another kind of warning:
Quote
include\cbplugin.h:169:22: warning: 'virtual bool cbPlugin::BuildToolBar(wxToolBar*, int&)' was hidden [-Woverloaded-virtual]
include\cbplugin.h:408:22: warning:   by 'virtual bool cbDebuggerPlugin::BuildToolBar(wxToolBar*)' [-Woverloaded-virtual]

Here:in cbPlugin:
        virtual bool BuildToolBar(wxToolBar* toolBar) = 0;
        virtual bool BuildToolBar(wxToolBar* toolBar, int &priority) { priority = 50; return BuildToolBar(toolBar); }


and in derived class:

virtual bool BuildToolBar(wxToolBar* toolBar);


Does cbPlugin::BuildToolBar(wxToolBar* toolBar, int &priority) really need to be virtual? I would fix that by making it non-virtual. Otherwise, you lose the method (or need to re-implement it) in the derived class.

jarod42

I would suggest to rename the method to avoid future similar warnings for derived class.

oBFusCATed

ptDev: If it is not virtual how would you change the priority?
jarod42: This is an option, too, but someone should come up with a good name - always a hard task.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

jarod42

#11
virtual int getPriority() const { return 50; }
or
virtual void changePriority(int& priority) { priority = 50; }

and then

bool BuildToolBarAndSetPriority(wxToolBar* toolBar, int &priority)
{
 changePriority(priority);
 return BuildToolBar(toolBar);
}


should be cleaner, I think.

ollydbg

Some days later, I rethink it. Now. follow jarod42's advice
The code

ToolbarInfo MainFrame::DoAddPluginToolbar(cbPlugin* plugin)
{
    ToolbarInfo info;
    info.toolbar = Manager::Get()->CreateEmptyToolbar();
    info.priority = 50;
    if (plugin->BuildToolBar(info.toolbar, info.priority))
    {
        SetToolBar(0);
        InitToolbar(info.toolbar);


becomes like below:

In base class, add a function:

virtual int GetToolBarPriority() { return 50; }


If some derived plugin class need to implement some other priority values, they should override their own.


ToolbarInfo MainFrame::DoAddPluginToolbar(cbPlugin* plugin)
{
    ToolbarInfo info;
    info.toolbar = Manager::Get()->CreateEmptyToolbar();
    //info.priority = 50;
    if (plugin->BuildToolbar(info.toolbar))
    {
        info.priority = plugin->GetToolBarPriority();
        SetToolBar(0);
        InitToolbar(info.toolbar);


Is it right?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

Quote from: oBFusCATed on June 15, 2012, 09:31:12 AM
Try it and see if it works...
I test it, and it works just fine.

Is the function name: GetToolBarPriority()  OK?

Ok to commit? (Include the change that remove the "virtual" keyword in operator=).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.