I was surprised to find the compiler gave no warnings or errors when compiling source code containing a function that specified a return value in its signature but didn't actually return anything
e.g.
int foo()
{
}
How can Netbeans be beefed up so it caches these things?
According to this question this is undefined behaviour but I would've thought this is something easy for an IDE to check for.
Also, is there a way to have it displays number of warnings at the bottom of the output window after compiling? For example the way it is by default, a warning could be buried in the amount of irrelevant information and easily missed.
How can Netbeans be beefed up so it caches these things?
Right click to project -> C++ Compiler set Warning Level to More Warnings (below Basic Options).
(Same applies to C Compiler settings)
Or:
Add -Wall to compiler flags.
For a maximum of warnings you can add these: -Wall -Wextra -pedantic
Also, is there a way to have it displays number of warnings at the bottom of the output window after compiling?
I guess there's no number yet, but possible this can help you: How to display all compile errors in Netbeans as a task list?
Related
I'm Flexing a file with the
%option nounput
Option and using the command line
flex --nounput
And flex version 2.5.35.
However, the cpp output still contains the line
#define unput(c) yyunput( c, (yytext_ptr) )
And this causes compilation problems with g++ since unput is not used.
Is there some way to fix this problem in a "clean" way? The two dirty ways are obvious:
Use unput in some useless way.
Remove the line automatically from the generated cpp file using some script.
(I tried to flag this question as "problem no longer reproducible" but the flag timed-out/aged away. I'm answering it so that it does not remain an open unanswered question.)
As mentioned by #akond:
I don't experience this problem. The version I am using is the same (flex 2.5.35). %option nounput does the trick for me.
I also tried this on version 2.5.4 and can confirm there is no issue. The option --nounput is no longer recognised or documented; however, the %option nounput remains in the manual.
The cpp output still does contain the line #define unput(c) yyunput( c, yytext_ptr ) but this does not seem to generate any g++ errors for me. Are you using -pedantic-errors or some other similar option perhaps?
Good program but badly out of date documentation.
I found that version 2.6.4 accepts the nounput option and does the right thing.
I am debugging my program with apache mina 2.0.2. The specific library is irrelevant.
The problem is that Eclipse can see internal structure of some classes and cannot see one of the others. No apparent differences visible for me: both classes have both code and source.
You can see that Eclipse draws arrow near AbstractPollingConnector class and does not so near AbstractPollingProcessor.
Of course Eclipse can't set line breakpoints inside "bad" classes.
What is the reason of it and what to do?
I guess, it depends whether the referenced classes were compiled with the debugger options on or off. According an older Javac manual, the -g switch seems related:
-g
Generate all debugging information, including local variables. By default, only line number and >source file information is generated.
-g:none
Do not generate any debugging information.
-g:{keyword list}
Generate only some kinds of debugging information, specified by a comma separated list of >keywords. Valid keywords are:
source
Source file debugging information
lines
Line number debugging information
vars
Local variable debugging information
I am attempting to use clock_gettime( CLOCK_MONOTONIC, ts ). I have included time.h, and linked to librt (I think). I still get the error that CLOCK_MONOTONIC is undefined. (EDIT: error text added)
Symbol 'CLOCK_MONOTONIC' could not be resolved ... Semantic Error
c++ in eclipse. In myrojname->properties->C/C++ Build->GCC C++ Linker->libraries I added "rt". The resulting command line includes -lrt.
I tried a much simpler scratch program and compiled from the command line with g++ -o mytest mytest.cpp -lrt and it works great.
So, what am I missing?
I think that's actually an error message coming out of the CDT static analyser, not something from the compiler itself.
And I think it's complaining about the code itself rather than something missing from the linkage objects, so whether you link with rt or not is not relevant (for this particular issue anyway).
You should go into the C++ settings, specifically the include paths, and ensure that all needed directories are listed there.
I compile my project with gcc compiler. One of example multi line warning is:
../../Source/Ctrl/SCmd.h: In constructor `STCPCommand::STCPCommand(char)':
../../Source/Ctrl/SCmd.h:273: warning: `STCPCommand::m_pGroup' will be initialized after
../../Source/Ctrl/SCmd.h:133: warning: `const char*STCPCommand::m_pcszSourceInfo'
../../Source/Ctrl/SCmd.h:141: warning: when initialized here
But I can't read it correctly in Problems view (Description).
What I get is 3 different warnings. All lines are in different places - according to sort method.
Is there any way to show this output without sorting ?
Maybe there is some gcc flag that will avoid splitting ?
The compiler complains about this, after I activated all kind of warnings:
For MyApp_Prefix.pch the compiler says:
warning: -Wuninitialized is not
supported without -O
What does that mean?
And for the uninitiated (like me), go to the Build Settings panel and filter the list for "Uninitialized Automatic Variables" then flip the flag to "No" to disable this warning. If your project file is selected this will apply across all build targets, or you can select a specific build target and change it per target.
In plain English, the compiler is complaining that it cannot check for uninitialized variables unless you turn on compiler optimization.
Chances are that it doesn't do quite such an exhaustive code path analysis if the optimizer is turned off and thus doesn't have all the necessary data to work out if a certain variable is uninitialized or not.
Simplest fix for the complaint is to turn off the warning for non-optimized builds and ensure that it's turned on for optimized release builds.
Turn on compiler optimizations.