Suggestion about r8512 commit

[daniloz]

Hi,

I've seen a lot of warnings that after r8512 (cbPlugin API change: replaced pure virtual functions with empty implementations, removing the necessity for every plugin to implement them, regardless of actual need.).

The warning is: "include/cbplugin.h:169:62: warning: no return statement in function returning non-void [-Wreturn-type]"

It comes from the new definition of BuildToolBar

Code Select Expand


virtual bool BuildToolBar(wxToolBar* /* toolBar */) {}


The way I see it, it should be:

Code Select Expand


virtual bool BuildToolBar(wxToolBar* /* toolBar */) { return false; }


Not really a problem though... I just thought it would be nice to report and get rid of the warnings... ;-)

[oBFusCATed]

Not really a problem though... I just thought it would be nice to report and get rid of the warnings... ;-)

In fact it is really a problem, because now this function returns random stuff

thomas: Please put -Werror=no-return in you advanced warning options, it catches such errors without a miss

[MortenMacFly]

The way I see it, it should be:

Code Select Expand


virtual bool BuildToolBar(wxToolBar* /* toolBar */) { return false; }


I had spotted this, too alreaedy - just was too lazy, to commit.

thomas: Please put -Werror=no-return in you advanced warning options, it catches such errors without a miss

Good point. Why don't we enforce a certain set of warnings to all project files? Whcih would be most wise?

[dmoore]

thomas: Please put -Werror=no-return in you advanced warning options, it catches such errors without a miss

Good point. Why don't we enforce a certain set of warnings to all project files? Whcih would be most wise?

Please do. You will have to correct far fewer of my script monkey mistakes if you do. Now if only you could get me to follow the style guide

[thomas]

-Werror=no-return

Good point, will do.

Note: -Werror=return-type it is.

[oBFusCATed]

Good point. Why don't we enforce a certain set of warnings to all project files? Whcih would be most wise?

Because gcc-4.1.2 doesn't support this one (for my home computer I have it enabled for all projects )
And because we won't agree on the list of warnings to enable.

[killerbot]

Good point. Why don't we enforce a certain set of warnings to all project files? Whcih would be most wise?

Because gcc-4.1.2 doesn't support this one (for my home computer I have it enabled for all projects )
And because we won't agree on the list of warnings to enable.

or we write some scripts for CB (put them in svn and have the cbp file use them, detecting the gcc version, and when high enough enable it. I remember we have done this before fpr something (I thin kI even did it, but can't remember) ...

[MortenMacFly]

I remember we have done this before fpr something (I thin kI even did it, but can't remember) ...

It was for the PCH stuff, or some warnings - I recall, too. It should still be in SVN somewhere or it has been merged to the project file as script.

[Jenna]

I remember we have done this before fpr something (I thin kI even did it, but can't remember) ...

It was for the PCH stuff, or some warnings - I recall, too. It should still be in SVN somewhere or it has been merged to the project file as script.

http://svn.berlios.de/wsvn/codeblocks/trunk/src/cbgcc420.script?peg=6000

[MortenMacFly]

http://svn.berlios.de/wsvn/codeblocks/trunk/src/cbgcc420.script?peg=6000

Exactly! And that's how we can do it properly, too btw. I didn't know it was a warning in the end, too...