We're using g++ 4.4.3, and one of our third-party libraries is causing the lovely error
/usr/include/c++/4.4/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
Since it's a third-party library, I can't fix the problem, so I just want to tell the compiler to suppress this warning for the one H file that causes the problem.
I tried a few things with
#pragma GCC diagnostic ignored "-Wdeprecated"
but I can't find which warning it is to specify (there is no "-Wdeprecated").
So is there any way I can suppress this warning just for the one offending H file? I'm hoping to do something like this:
// Turn off the warning
#pragma GCC diagnostic ignored "-Wdeprecated"
#include "BadFile.h"
// Turn the warning back on
#pragma GCC diagnostic warning "-Wdeprecated"
I could not figure out a way to do this with pragma's, only by passing -Wno-deprecated on the command line. So if you are desperate you could try:
#undef __DEPRECATED
// include offensive headers here...
#define __DEPRECATED
But note that I definitely don't condone undef'ing system level #defines :-P
Related
Since Xcode 6.3, types in Objective-C can be marked with nullable or nonnull, here is Apple's blog post about this.
Problem is, when neither is specified, then the compiler imports the Objective-C code as implicitly unwrapped into Swift, e.g. NSView!. So when an object actually is nil, then it will crash when accessed from Swift. This does not produce a compiler error.
As this is extremely prone to fail, I'd like the compiler to assume everything from Objective-C by default as nullable, except when otherwise specified via nonnull, or the audited region macros NS_ASSUME_NONNULL_BEGIN / END. How can that be achieved?
Not exactly what you are looking for but from Xcode 7, you can turn on CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION in LLVM complier settings by passing -Wnullable-to-nonnull-conversion flag in complier flag.
This will warn if there is a implicit conversion from nullable to non-nullable conversion.
Seems like there is no way around adding nullability annotations in order to get rid of implicitly unwrapped optionals.
I wrote a script that finds all non-annotated headers which can also be added as a build phase, so no headers are overlooked.
Since the macro is defined as:
#define NS_ASSUME_NONNULL_BEGIN _Pragma("clang assume_nonnull begin")
#define NS_ASSUME_NONNULL_END _Pragma("clang assume_nonnull end")
It may be worth trying to see if there's a corresponding assume_nullable macro.
#define XX_ASSUME_NULLABLE_BEGIN _Pragma("clang assume_nullable begin")
#define XX_ASSUME_NULLABLE_END _Pragma("clang assume_nullable end")
I only did a quick test to check if this pragma fails compilation, which it didn't. But I haven't tested whether this produces the expected results in Swift.
I was reading the clang documentation on reference counting, which says that “ By default in Objective-C, ARC is not exception-safe”. It proceeds to say:
A program may be compiled with the option -fobjc-arc-exceptions in order to enable these, or with the option -fno-objc-arc-exceptions to explicitly disable them, with the last such argument “winning”.
In Objective-C++, -fobjc-arc-exceptions is enabled by default.
I was intrigued. Are there any other compiler options whose default change between Objective-C and Objective-C++?
Complementary question: what is difference between compiling purely Objective-C code with clang in Objective-C++ mode (*.mm files) rather than in Objective-C mode only (*.m)?
Best way is to log what clang will output from all those c language
here's some of what i have got from a obj-c++ compilation
clang++ -fobjc-arc main.mm -v
/.../
-fblocks
-fobjc-runtime=macosx-10.7.0
-fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties
-fobjc-arc
-fobjc-arc-cxxlib=libstdc++
-fobjc-arc-exceptions
-fobjc-exceptions
-fcxx-exceptions
-fexceptions
-fdiagnostics-show-option
-fcolor-diagnostics
/.../
As you can see those output can vary depending from where you compile it. But some of them are constants.
You should try on different c families files in order to determine what the default option are for these respective.
Hope it will help you.
To answer the second part of your question: If you compile files in Objective-C mode rather than Objective-C++ mode, you get better support from the Static Analyzer [1]. I believe the compiler will also generate more accurate warnings in general (without using the Static Analyzer), but I cannot find/remember the source of that information.
Is there a RELEASE defined or maybe it is by another name?
I kind of not want to use
#ifndef DEBUG
#endif
because the n may be less obvious than if we use a RELEASE, which is quite clear.
If none is available, then is adding the following to Support Files/project_name.pch a good way to have RELEASE defined?
#ifndef DEBUG
#define RELEASE 1
#endif
DEBUG is just defined in Xcode's Build Settings under Preprocessor Macros. In that section you can specify macros to be defined for all builds, debug builds or release builds. Just add RELEASE to the release section and you have what you want; or if you prefer #if over #ifdef put DEBUG=1, RELEASE=0 into the debug section and DEBUG=0, RELEASE=1 into the release section.
(And if you're not using Xcode your build system/compiler should have similar facilities.)
Is there a #pragma (or otherwise some construct) to explicitly enable automatic reference counting (ARC) in an Objective-C (or Objective-C++) source file? Even better if the source file can cause compilation to fail if ARC is not enabled.
I'm starting to have a number of ARC-only source files that can be potentially shared with other projects. Most of these contain category methods to extend built-in classes. I just don't want to accidentally include these in a non-ARC project and starts leaking out memory.
Thanks in advance!
As far as I can tell there is no way to explicitly enable or disable ARC.
However it is possible to detect if it is enabled. Simply add the following snippet to any file that requires ARC.
#ifndef __has_feature
#define __has_feature(x) 0 /* for non-clang compilers */
#endif
#if !__has_feature(objc_arc)
#error ARC must be enabled!
#endif
More info:
http://clang.llvm.org/docs/AutomaticReferenceCounting.html
http://clang.llvm.org/docs/LanguageExtensions.html#__has_feature_extension
I am working on a project that relies on compiler optimisations but I need some code not to be optimised by GCC. Is this possible?
GCC 4.4 has an attribute for that:
int foo(int i) __attribute__((optimize("-O3")));
It is documented at: https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Function-Attributes.html#index-g_t_0040code_007boptimize_007d-function-attribute-3195
GCC has since 4.4. the #pragma GCC optimize ("whatever"). I would also recommend to wrap the particular code, that is annotated with this pragma with #pragma GCC push_options and #pragma GCC pop_options. The first will save the options as they were before your change, the later will restore them afterwards and the rest of the code will compile with the global options.
For details on the whatever string, you should look into the gcc doc, here the most important part of it: Arguments can either be numbers or strings. Numbers are assumed to be an optimization level. Strings that begin with O are assumed to be an optimization option, while other options are assumed to be used with a -f prefix..
That means if you dont want any optimizations on your particular code your whatever should just be "0".
You can put that piece of code into a different file and compile it without optimisations.
Or try to use the #pragma directive:
#pragma optimize level=0
Or even better start and stop optimization with :
#pragma OPTIMIZE ON
#pragma OPTIMIZE OFF