The new c++ keyword constexpr is not highlighted by vim. I have tried plugins like this one:
http://www.vim.org/scripts/script.php?script_id=4617
It worked very well for everything else except constexpr.
Does anyone know how I can turn syntax highlight on for constexpr in my cpp.vim (or by using other methods)?
In vim 7.4 (and probably earlier, but 7.4 is what I have installed), constexpr should be set up by the standard cpp.vim file, which should be a part of your installation.
It is, however, guarded in a test for the cpp_no_cpp11 variable:
" C++ 11 extensions
if !exists("cpp_no_cpp11")
syn keyword cppType override final
syn keyword cppExceptions noexcept
syn keyword cppStorageClass constexpr decltype
syn keyword cppConstant nullptr
endif
You can :echo exists("cpp_no_cpp11"); if the result is 1, that would explain why you don't see the highlighting (you'll have to diagnose your configuration to see why it's getting set, though).
Alternatively you can go for a brute force method and put
syn keyword cppStorageClass constexpr
in your .vimrc (along with whatever other else you want; seems like you'll also be missing decltype, et cetera). Or you can put the command in a script file that you load via autogroup or using the "after" directory (like the plugin you linked) if you want to be gentler in your approach.
(Note that the plugin you linked doesn't attempt to add C++11 keyword highlighting at all, at least not for constexpr. It's mostly concerned with functions and type names.)
Related
I'm trying to replace the global new operator in Visual Studio and C++. This is my code (only one new operator shown for simplicity):
void* operator new(size_t _Size)
{
// Do something
}
It works fine, however Visual Studio is giving me a warning when running Code-Analysis for my project:
warning C28251: Inconsistent annotation for 'new': this instance has no annotations. The first user-provided annotation on this built-in function is at line vcruntime_new.h(48).
Using the annotations from vcruntime_new.h for my operator new replacement, as suggested in the warning from IntelliSense, resolves the warning:
_NODISCARD _Ret_notnull_ _Post_writable_byte_size_(_Size) _VCRT_ALLOCATOR
void* __cdecl operator new(size_t _Size)
{
// Do something
}
Is it safe to use the annotations inside vcruntime_new.h for my own replacement code like shown above?
What are the consequences of this change?
Are there special use cases were the "new operator" cannot be used anymore like before because of the annotations?
And why is that change necessary?
EDIT:
Am I correct, that the annotations won't change anything in the resulting binary, and are simply for static code analysis? (Except __cdecl, which changes the assembler, but it should be standard anyway I guess?)
This applies to _Ret_notnull_ and _Post_writable_byte_size_(_Size):
Is it safe to use the annotations inside vcruntime_new.h for my own replacement code like shown above?
Yes, as long as your operator new actually follow these rules in annotation. It might not follow _Ret_notnull_ (for example non-throwing new returns nullptr), tough normally will. But it should follow _Post_writable_byte_size_(_Size), since operator new is required so.
What are the consequences of this change?
Annotations will probably help Visual Studio Code Analysis pinpoint errors, but will make you using non-standard stuff, making your program less portable and less clear.
Are there special use cases were the "new operator" cannot be used anymore like before because of the annotations?
No.
And why is that change necessary?
Because you want to avoid that warning instead of silencing it.
Am I correct, that the annotations won't change anything in the resulting binary, and are simply for static code analysis? (Except __cdecl, which changes the assembler, but it should be standard anyway I guess?)
Correct. Not even optimizer would use that (optimizer would use __assume, __restrict, and other annotations separate from static analysis).
I have found the large-precision code of MPFR C++ to be very useful, and have used it successfully in the past. Recently, while developing a new app, I encountered an enormous number of compiler errors in their header code (mpreal.h). I have identified the cause of all these errors: the the use of a name both in a typedef and as the name of a function, coupled with an unintuitive result of a macro. The relevant macro was in the mpfr package, and occurred between mpfr 4.0.2-5 and 4.1.0-6. I am using the latest version of mpreal.h (version 3.6.8), but other earlier versions behave the same.
The compiler errors vary somewhat, but the following is typical:
In file included from mpreal.h:125:
mpreal.h:624:32: error: no matching function for call to ‘mpfr::mpreal::mpfr_srcptr(const __mpfr_struct*&)’
624 | mpfr_init2(mpfr_ptr(), mpfr_get_prec(u));
| ^~~~~~~~~~~~~
mpreal.h:324:19: note: candidate: ‘const __mpfr_struct* mpfr::mpreal::mpfr_srcptr() const’
324 | ::mpfr_srcptr mpfr_srcptr() const;
| ^~~~~~~~~~~
mpreal.h:324:19: note: candidate expects 0 arguments, 1 provided
The relevant lines of code (int addition to the above) are:
mpreal.h:125 #include <mpfr>
mpfr.h:866 #define mpfr_get_prec(_x) MPFR_VALUE_OF(MPFR_SRCPTR(_x)->_mpfr_prec)
mpfr.h:845 #define MPFR_VALUE_OF(x) (0 ? (x) : (x))
mpfr.h:847 #define MPFR_SRCPTR(x) ((mpfr_srcptr) (0 ? (x) : (mpfr_srcptr) (x)))
The problem seems to be in the macro of line 847. The (mpfr_srcptr) (x) appearing in MPFR_SRCPTR(x) is meant to be a type-cast of x to the type mpfr_srcptr, but is being interpreted to mean a call to mpfr_srcptr() with argument x. Outside of a macro, gcc can tell the difference between (mpfr_srcptr)(x) and mpfr_srcptr(x), but the macro is apparently ignoring the parentheses. Can anyone explain this macro behavior? I know that gcc has a huge number of switches to control almost everything, but is there an option somewhere that would affect the interpretation of parentheses in macros?
I suppose that this behavior could be unique to my system, but I find that hard to believe. But I also find it hard to believe that such a bug has gone unnoticed by the rest of the community; I found no suggestion of any problem either on the website or on github, to which the project has recently been transferred.
The macro SRCPTR is not ignoring parentheses as I originally thought; the behavior is explained by the difference in scopes. The SRCPTR macro, while occurring within the mpfr coding at global scope, is actually being called from mpreal's scope. Since mpreal has redefined srcptr as a function, that definition is the only one used when SRCPTR is executed from mpreal. (SRCPTR, being a macro, has no scope.) When mpfr's functions are called from mpreal, the functions operate with the global scope, and the SRCPTR macro invoked there would therefore use the global definition.
I am working on a project with the library ADOL-C (for automatic differentiation) using gcc. Right now I am trying to recompile the library to use the parallelization features however the make process does not working apparently due to some preprocessor stuff.
I think the problematic line is :
#define ADOLC_OPENMP_THREAD_NUMBER int ADOLC_threadNumber
However I could not find what it means. Does it make a link between two variables? Also ADOLC_threadNumber has not been declared before...
The preprocessor doesn't even know what a variable is. All that #define does is define a short(long?)hand for declaring a variable. I.e., if you type
ADOLC_OPENMP_THREAD_NUMBER;
It becomes
int ADOLC_threadNumber;
It's just a text substitution. Everywhere in code where ADOLC_OPENMP_THREAD_NUMBER appears, it's substituted by int ADOLC_threadNumber.
As far as I see it, the line with the define itself is not problematic, but maybe the subsequent appearance of ADOLC_OPENMP_THREAD_NUMBER. However, to check this, we need to know more about the context.
#define is a directive used often in .h files,
it creates a macro, which is the association of an identifier or parameterized identifier with a token string.
After the macro is defined, the compiler can substitute the token string for each occurrence of the identifier in the source file.
#define may be associated with #ifndef directive to avoid to delare the identifier more than once :
#ifndef ADOLC_OPENMP_THREAD_NUMBER
#define ADOLC_OPENMP_THREAD_NUMBER int ADOLC_threadNumber
#endif
MingGW's gcc (4.8.1) reports the following error (and more to come) when I try to compile Expstack.c:
parser.h:168:20: error: field '__p__environ' declared as a function
struct term *environ;
where 'environ' is declared inside 'struct term{ ... }'. In unistd.h you find
char **environ
but nowhere a '__p__environ'.
Some other fields are declared likewise, but are accepted. Subsequent errors related to environ are reported as follows
Expstack.c:1170:38: error: expected identifier before '(' token
case Term_src: return e->item.src->environ;
^
Cygwin's gcc (4.8.3) accepts these constructs and has done so over various versions since
2006 at least, and gcc with various versions of Linux before that.
The source text uses CRLF despite my attempts to convert to DOS, and this is my only guess for an explanation.
I'll appreciate clues or ideas to fix the problem, but renaming the field is not especially attractive and ought to be totally irrelevant.
This is very unlikely to have to do with CR/LF.
The name ought to be irrelevant but it isn't: this one relates to the Windows integration that MinGW does and Cygwin does not, as alluded to in http://sourceforge.net/p/mingw/mailman/message/14901207/ (that person is trying to use an extern environ that it expects to be defined by the system. Clearly, the fashion in which MinGW developers have made this variable available breaks the use of the name as a struct member).
You should report this as a MinGW bug. Unpleasant as it may be, in the interim, renaming the member is the simplest workaround. It is possible that a well-placed #undef environ might help, but no guarantees.
In the process of getting rid of old macros in our code, I need to define the old macro as an error with a meaningful compiler message.
E.g., old code:
#define DIVIDE_BY_TWO(x) x/2
In the new code, to prevent the usage of this macro I'd like to write:
#define DIVIDE_BY_TWO(x) #error DIVIDE_BY_TWO is obsolete, use DIV_2 instead
But when I compile the above line I get:
error C2162: expected macro formal parameter
What is the correct way to do it?
A macro can't have directives or change the preprocessor state. You could leave DIVIDE_BY_TWO undefined, but then it doesn't help to find the replacement macro. The only way to do it portably is to define it as something like this:
#define DIVIDE_BY_TWO error_DIVIDE_BY_TWO_is_obsolete_use_DIV_2_instead
Which should give an error that error_DIVIDE_BY_TWO_is_obsolete_use_DIV_2_instead is not defined and hopefully that will give enough hints has to how to replace it.
The problem with using #error is that creates an error at the time that part of the code is analyzed by the preprocessor. You want to create an error when the macro is expanded. You can't, unfortunately, use #error for that.
I don't believe there is a way to generate a clear human-readable error message reliably in portable C. (You can, of course, make the macro expand to something that's syntactically invalid, though, which will at least stop compilation.) gcc supports doing it with _Pragma. Your question is effectively equivalent to this question and the answer there explains how to use _Pragma as well as other options for creating a fatal error.
You cannot use a preprocessor directive in #define since what you're asking for is to run the preprocessor twice.
If a line begins with an # it is a directive to the preprocessor and would be interpreted. If it doesn't, then it is subjected to macro substituion and replacement if such a macro exists.
The best you could do is to define the deprecated macro as some expression that would return an error for sure.