I am getting a lot of these warnings from 3rd party code that I cannot modify.
Is there a way to disable this warning or at least disable it for certain areas (like #pragma push/pop in VC++)?
Example:
list.h:1122: warning: `list<LogOutput*, allocator<LogOutput*> >::node_alloc_' will be initialized after
list.h:1117: warning: `allocator<LogOutput*> list<LogOutput*, allocator<LogOutput*> >::alloc_'
Make sure the members appear in the initializer list in the same order as they appear in the class
Class C {
int a;
int b;
C():b(1),a(2){} //warning, should be C():a(2),b(1)
}
or you can turn -Wno-reorder
You can disable it with -Wno-reorder.
For those using QT having this error, add this to .pro file
QMAKE_CXXFLAGS_WARN_ON += -Wno-reorder
use -Wno-reorder (man gcc is your friend :) )
Class C {
int a;
int b;
C():b(1),a(2){} //warning, should be C():a(2),b(1)
}
the order is important because if a is initialized before b , and a is depend on b. undefined behavior will appear.
If you're seeing errors from library headers and you're using GCC, then you can disable warnings by including the headers using -isystem instead of -I.
Similar features exist in clang.
If you're using CMake, you can specify SYSTEM for include_directories.
The order of initialization doesn’t matter. All fields are initialized in the order of their definition in their class/struct. But if the order in initialization list is different gcc/g++ generate this warning. Only change the initialization order to avoid this warning. But you can't define field using in initialization before its construct. It will be a runtime error. So you change the order of definition. Be careful and keep attention!
Related
i've activated warnings with doxygen
WARNINGS = YES
WARN_IF_UNDOCUMENTED = YES
WARN_IF_DOC_ERROR = YES
WARN_NO_PARAMDOC = YES
But undocumented methods like this one:
void AnimationManager::setAnimationTimeStep( double timeStep )
{
...
}
Do not throw any warning during doxygen generation.
Is there any way to display warning in this situation ?
Same problem with undocumented return , for example
/**
* #brief brief description
*/
bool AnimationManager::hasAnimationTimeStep( )
{
...
}
Does not throw warning for undocumented return
When you are missing warnings that you would otherwise expect, check whether EXTRACT_ALL is set to YES.
From the commented version of the doxyfile:
# Note: This will also disable the warnings about undocumented members that are
# normally produced when WARNINGS is set to YES.
Using EXTRACT ALL can be useful for a first pass or to extract something from a non-doxygenned source, but in general it's a good idea to aim to be able to turn this off and thus be able to get the warnings that refine the parts that you actually need documented.
I downloaded XCDFormInputAccessoryView from github https://github.com/0xced/XCDFormInputAccessoryView. I tried to run it in xcode and receive numerous warnings of
instance variable "---" is being directly accessed. Any help??
- (void) setTextInputs:(NSArray *)textInputs
{
// Some day, IBOutletCollection will be properly sorted, in the meantime, sort it!
_textInputs = [textInputs sortedArrayUsingComparator:^NSComparisonResult(UIView *view1, UIView *view2) {
return [#(view1.tag) compare:#(view2.tag)];
}];
}
Add -Wno-direct-ivar-access to the Warning Flags under Build Settings.
It's the result of Cedric turning on the -Weverything flag, which makes LLVM generate pedantic warnings. Remove the flag under your build settings:
Then recompile, and the errors should go away.
If you'd like to retain as many warnings as practical, this is a strategy you could use in your base .xcconfig file:
TWX_BASE_WARNING_EXCLUSIONS = -Wno-bad-function-cast -Wno-format-nonliteral -Wno-objc-missing-property-synthesis -Wno-pedantic -Wno-unused-macros -Wno-used-but-marked-unused -Wno-selector -Wno-direct-ivar-access
WARNING_CFLAGS = -Weverything $(TWX_BASE_WARNING_EXCLUSIONS)
Personally, I have stacked .xcconfig files so the "base" there is as opposed to other files in the stack,
WARNING_CFLAGS = -Weverything $(TWX_BASE_WARNING_EXCLUSIONS) $(TWX_CONFIGURATION_WARNING_EXCLUSIONS)
and the same strategy is used for managing search paths, preprocessor definitions, etc.
I need to recover method names dynamically, via reflection calls at runtime. But get strange results for some.
My TestClass contains a method like:
- (void)testMethod6_NSRect:(NSRect)a1 int:(int)a2 int:(int)a3 bool:(Boolean)a4 {
...
}
When enumerating the above classes methods using class_copyMethodList() and fetching the method selectors via method_getName(), I get:
"testMethod6_NSRect:int:int:_Bool:"
Thus, the selector was rewritten somehow (by gcc?) to make "_Bool" from "bool". As far as I tested yet, this seems to be done only for a "bool" selector-part - if I change it to int:(int), as in:
- (void)testMethod1_int:(int)a1 int:(int)a2 int:(int)a3 int:(int)a4 {
...
}
I get the expected:
"testMethod1_int:int:int:int:"
Q:
Does anyone know the rules or a pointer to where I could find them for this "selector rewriting", or am I missing something? Is this only done for "bool"?
I also need to know if this behavior is depending on the gcc-version, osx-version or runtime library version.
I am using (gcc --version):
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
on a (uname -a)
10.8.0 Darwin Kernel Version 10.8.0:
The problem lies in an ugly piece of preprocessor magic in the C99 standard header <stdbool.h>:
#define bool _Bool
C99 defines a type named _Bool which behaves like C++'s bool type. The define is there to be able to use it in C but with the C++ identifier.
Solution:
#undef bool
Try using BOOL instead of Boolean
When I generate my parser with bison, I obtain this warning:
warning: stray `#'
But that is because I have some legal Objective-C code containing #, for instance this is one of the rules having the warning:
file : axiom production_rule_list { NSLog(#"file"); }
;
Is there any risk to use # in the code? If not, how to tell bison that it is a legitimate use of #?
Thanks in advance.
The message is just a warning. You can ignore it. If you're using Xcode, it won't even show you the warning in its Issue Navigator.
Rename your Bison input file to have a .ym extension instead of a .y extension. That tells Xcode that it's a grammar with Objective-C actions.
If you want to suppress the warning, you can use a #define AT #.
The code in the braces is just copied, apart from replacing the $… sequences with the code to give the relevant token. This appears to work fine with Objective-C, although if you're using ARC, you might need to do some digging (or just add extra blocks (in the C sense)) to make sure that objects are freed as soon as possible.
As per the documentation in Actions - Bison 2.7, it appears that the code between the curly braces is expected to be C code. As such I doubt that you can use objective-c constructs there.
However you could create an external C function to do the work for you like:
Logit(char* message)
{
NSLog(#"%s",message);
}
And use that in the Bison action
file : axiom production_rule_list { Logit("file"); }
;
i have a module 'gvars' defined for my global variable declarations. when i define
integer :: nthreads, max_threads, tid, omp_get_max_threads, omp_get_num_threads, omp_get_thread_num inside of my gvars module, the call maxthreads = omp_get_max_threads() in my main routine gives me the following error upon compilation:
maxthreads = omp_get_max_threads()
1
Error: Unclassifiable statement at (1)
but when i include the integer :: definitions above inside my main routine, it compiles just fine and gives me the desired results. if i even go as far as to define nthreads = -1 inside my gvars module, i am able to print out the correct value in my main routine so i know it is being included and defined correctly, it's just that for some reason i cannot have it as a return value from openmp functions.
why would this be?
is there any other way to keep these values as global variables and still define them in my main routine instead of a module?
if it matters, i am using gfortran to compile
The problem is not with the declaration of maxthreads, but with the declaration, on the same line, of omp_get_max_threads. As haraldkl showed, you need to use omp_lib instead, to automatically get access to the declarations of these functions.
(If for some reason you really don't want to do it that way, you can also add the statement external :: omp_get_max_threads, ... to the module.)
Not really an answer, but I do not know how else to put the code in here. Sorry...
module gvars
integer :: maxthreads
end module gvars
program test
use gvars
use omp_lib
implicit none
maxthreads = omp_get_max_threads()
end program test
compiled with:
gfortran -fopenmp test.f90
Where gfotran -v gives:
gcc version 4.4.5 (GCC)