I have this Objective-C istruction:
NSRange range = NSMakeRange(i, MIN(a, b));
where a and bare NSUIntegers.
MIN() is the macro defined in the standard NSObjCRuntime.hheader file as:
#if !defined(MIN)
#define MIN(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __a : __b; })
#endif
During the compilation, the LLVM Compiler 4.1 highlights my instruction showing the warning: "Use of GNU statement expression extension".
What does this mean? Is it my fault? If yes, how can I fix it? If not, how can I remove the compiler warning?
It’s a late answer, I know, but you can avoid this message by adding -Wno-gnu to your compiler flags.
(In Xcode 5 I believe you can change this by going to your project’s Build Settings and adding -Wno-gnu to the “Other C Flags”, which are in the “Apple LLVM 5.0 – Custom Compiler Flags” section.)
"Statement expressions" is an extension of the GNU C compiler and allows you to execute a group of statements, returning the value of the last statement:
x = ({
statement1;
statement2;
statement3;
});
In the above example, x will have the value returned by statement3.
It is a convenient feature that enables you to have multi-statement macros that can be nested easily into other expressions. It is not, however, defined by any C standard.
Don't use -Wno-gnu, that shuts down too many warnings. Instead, use:
-Wno-gnu-statement-expression
Statement expressions have been declared.
You can selectively ignore the warning by using pragma codes without changing project settings.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wgnu"
NSRange range = NSMakeRange(i, MIN(a, b));
#pragma GCC diagnostic pop
Related
I have a C++ project and I want to test the compatibility of library headers with different compiler versions. I have a simple source file (that includes said headers) and I want to change the compiler argument to std=gnu++11 for this one target. How do I do that?
executable('old_compiler_test', ['octest.cxx']
# override ARGS here ??? how
)
Note that I have
add_global_arguments(
['-std=gnu++17',
....
rather than the dedicated option for this, in spite of the warning to prefer the special option, because the special option simply doesn't work. (Why is a question I've never tracked down)
update
To clarify: I'm not trying to make additional configurations in the same way that debug and release are configurations. I want a different compiler argument to be applied to a single target within the configuration.
From the Meson documentation, you can use the argument <languagename>_args to pass additional compiler arguments. In your case, since you use C++, it would give something like
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['std=gnu++11']
)
However the documentation also specify that there are no way to disable an argument added by add_global_argument(), so you will end up with both -std=gnu++17 and -std=gnu++11 passed to the compiler. I don't know how your compiler will behave, but I tried to pass both arguments to GCC 10.2 and it uses c++17 (not what you want).
Workaround
It seems that if you define the C++ version in the project() statement, Meson will removes it if an other version is specified in compiler arguments, giving the behaviour you expect.
Here is the sample I used:
meson.build
project('project-name', 'cpp',
default_options: ['cpp_std=c++17']
)
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['-std=gnu++11']
)
octest.cxx
#include <iostream>
int main() {
std::cout << __cplusplus << std::endl;
}
After compilation, running the executable will print 201103, which means that the compiler used c++11 as desired.
Hi was reviewing some Objective-C code and found out the following statement:
OBJC_EXTERN void CLSLog(NSString *format, ...) NS_FORMAT_FUNCTION(1,2);
What does this mean?
Also, what is supposed to be the syntax of this statement?
Thanks in advance.
OBJC_EXTERN is defined in <objc/objc-api.h> as
#if !defined(OBJC_EXTERN)
# if defined(__cplusplus)
# define OBJC_EXTERN extern "C"
# else
# define OBJC_EXTERN extern
# endif
#endif
and therefore prevents "C++ name mangling" even if the above declaration is
included from a C++ source file, as for example explained here:
In C++ source, what is the effect of extern "C"?
For pure C code, you can just remove the OBJC_EXTERN, because the extern
keyword is not needed in a function declaration.
NS_FORMAT_FUNCTION is defined as
#define NS_FORMAT_FUNCTION(F,A) __attribute__((format(__NSString__, F, A)))
and __attribute__((format(...))) is a GCC specific extension, also understood
by Clang:
http://clang.llvm.org/docs/LanguageExtensions.html#format-string-checking
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
It allows the compiler to check the number and types of the variable argument list
against the format string. For example
CLSLog(#"%s", 123);
would cause a compiler warning, because %s is the placeholder for a string,
but 123 is an integer.
I have tested a bit of assembler on Linux using the AT&T syntax. One thing that struck me was that the book I was reading was written from a 32-bit standpoint. Thus, all sizes would have to be changed to the correct 64-bit versions for me. Or I could (which I did) assemble the code using the --32 flag for as and the -melf_i386 flag for ld when linking. I have also adapted some of the code and to run on Windows under Cygwin.
But that got me thinking. Is there a way to do ifdef like checks in assembler to do one thing if I'm on Windows and another under Linux and also handle 32 vs 64 bit that way? For example to have a .globl _start under Linux and a .globl _main under Windows.
Or is this handled by checking before assembling and having different source files to assemble based on the result of the checks?
I.e. foo_linux.s and foo_windows.s
If so, how do you overcome that fact that you will not know which .s files you will use, and thus have to include, when you are creating your program?
For example, say that we have a socket_linux.s and a socket_windows.s. They both present an identical interface but do the OS specific work associated to sockets. But when I work with the sockets in my program I will not know if I need the Windows or Linux version included. So I would be kinda screwed :)
So how is this handled in Assembler? In C++ for example I could include my socket.h and socket.cpp and wrap all the Linux and Windows specific code in #ifdef statements.
If you use GCC to compile your files and name them .S (with uppercase S) or .sx, it will pass them through the preprocessor before invoking the assembler.
From the docs:
file.s
Assembler code.
file.S
file.sx
Assembler code which must be preprocessed.
You can add -v to the command line to see how the various sub-processes are invoked.
in MASM (.asm), you can use ifdef, ifndef and the likes, as:
ifdef X64
endif
When writing for different platforms you can define some macro for loading target specific files:
FILE target.h
#if defined(__arm__)
#define target "arm"
#elif defined(__x86_64__)
#if defined(_WIN64)
#define target "win64"
#else
#define target "linux64" // all non-Win share the same calling convention
#endif
#else
// 32bit defs
#endif
Then you can include target specific files with the macro, two string literals successively get one single literal:
#include "target.h"
#include "target_specific_code_" target ".h"
It includes one of these files:
target_specific_code_arm.h
target_specific_code_win64.h
target_specific_code_linux64.h
...
EDIT:
Like this, you can also define target specific assembler instructions for later use in inline assembly:
#ifdef ...
#define ASM_PP_LOAD_WORD "movi "
#else
#define ASM_PP_LOAD_WORD "mov "
#endif
or as macro
#ifdef ...
// when using intel assembler there is a different
// order of parameters
#define ASM_PP_LOAD_WORD(a, b) "movi " #b ", " #a
#else
#define ASM_PP_LOAD_WORD(a, b) "mov " #a ", " #b
#endif
What's the closest GCC equivalent to this MSVC preprocessor code?
#pragma warning( push ) // Save the current warning state.
#pragma warning( disable : 4723 ) // C4723: potential divide by 0
// Code which would generate warning 4723.
#pragma warning( pop ) // Restore warnings to previous state.
We have code in commonly included headers which we do not want to generate a specific warning for. However, we want files which include those headers to continue to generate that warning (if the project has that warning enabled).
This is possible in GCC since version 4.6, or around June 2010 in the trunk.
Here's an example:
#pragma GCC diagnostic push
#pragma GCC diagnostic error "-Wuninitialized"
foo(a); /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
#pragma GCC diagnostic pop
foo(c); /* error is given for this one */
#pragma GCC diagnostic pop
foo(d); /* depends on command line options */
The closest thing is the GCC diagnostic pragma, #pragma GCC diagnostic [warning|error|ignored] "-Wwhatever". It isn't very close to what you want, and see the link for details and caveats.
I've done something similar. For third-party code, I didn't want to see any warnings at all. So, rather than specify -I/path/to/libfoo/include, I used -isystem /path/to/libfoo/include. This makes the compiler treat those header files as "system headers" for the purpose of warnings, and so long as you don't enable -Wsystem-headers, you're mostly safe. I've still seen a few warnings leak out of there, but it cuts down on most of the junk.
Note that this only helps you if you can isolate the offending code by include-directory. If it's just a subset of your own project, or intermixed with other code, you're out of luck.
This is an expansion to Matt Joiner's answer.
If you don't want to spawn pragmas all over your code, you can use the _Pragma operator:
#ifdef __GNUC__
# define DIAGNOSTIC_ERROR(w) _Pragma("GCC diagnostic error \"" w "\"")
# define DIAGNOSTIC_IGNORE(w) _Pragma("GCC diagnostic ignore \"" w "\"")
# define DIAGNOSTIC_PUSH _Pragma("GCC diagnostic push")
# define DIAGNOSTIC_POP _Pragma("GCC diagnostic pop")
#endif
// (...)
DIAGNOSTIC_ERROR("-Wuninitialized")
foo(a); // Error
DIAGNOSTIC_PUSH
DIAGNOSTIC_IGNORE("-Wuninitialized")
foo(a); // No error
DIAGNOSTIC_POP
foo(a); // Error
I'm working on converting a Linux project of mine to compile on Windows using MinGW. It compiles and runs just fine on Linux, but when I attempt to compile it with MinGW it bombs out with the following error message:
camera.h:11: error: declaration does not declare anything
camera.h:12: error: declaration does not declare anything
I'm kind of baffled why this is happening, because
I'm using the same version of g++ (4.4) on both Linux and Windows (via MinGW).
The contents of camera.h is absurdly simple.
Here's the code. It's choking on lines 11 and 12 where float near; and float far; are defined.
#include "Vector.h"
#ifndef _CAMERA_H_
#define _CAMERA_H_
class Camera{
public:
Vector eye;
Vector lookAt;
float fov;
float near;
float far;
};
#endif
Thanks for your help.
EDIT: Thanks both Dirk and mingos, that was exactly the problem!
Edit If you happen to include windef.h (either directly or indirectly), you will find
#define FAR
#define far
#define NEAR
#define near
there. I think, that this is the culprit.
Try
#undef near
#undef far
before your class definition.
Try giving them different names, like
float my_near;
float my_far;
I recall Borland using "near" and "far" as keywords (my 1992 Turbo C had these, back in MS-DOS era). Dunno if this is the case with gcc, but you can always try that.
In <windef.h>, you'll find on the following lines:
#define NEAR
#define near
Simple answer: you can't #undef them because they're a part of the Windows headers (_WINDEF_H will still be defined even if you #undef those definitions, so it won't be re-included if you try to #include <windef.h> again, not to mention the fact that if you #undef _WINDEF_H before using #include <windef.h> after your class definition, you'll end up with duplicate definitions for things like RECT, LONG, PROC and more), so the only other solution is to change your variable names.