I have some Microsoft code (XLCALL.CPP) which I am trying to compile with CodeBlocks/MinGW.
At this line I get a compile time error:
__forceinline void FetchExcel12EntryPt(void)
This is the error message I get:
XLCALL.CPP|36|error: expected constructor, destructor, or type
conversion before 'void'
This error is expected, because __forceinline is a Microsoft specific addition to the language, not recognized by GCC.
So, to get things compile, I try to add thiese defines in CodeBlocks (Project Build Options/Compiler Settings/#defines):
#define __forceinline inline
#define __forceinline
However I still get the same error.
If in the dialog I do not specify the #define preprocessor command (i.e.: __forceinline inline), this is what I get:
XLCALL.CPP|36|error: expected unqualified-id before numeric constant
Is there a way to compile such a piece of code, without using Visual C++?
The syntax is __forceinline=inline, as you've noted in the comments, because these settings get turned into -D options to GCC.
Note that inline is a strong hint to GCC that the function should be inlined, but does not guarantee it. The GCC equivalent of __forceinline is the always_inline attribute - e.g. this code:
#define __forceinline __attribute__((always_inline))
or equivalently this setting:
__forceinline="__attribute__((always_inline))"
(But this might well be unnecessary: if there was some particularly good reason for forcing this function to be inlined when compiling with MSVC, that reason may well not be valid when using a completely different compiler!)
Related
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'm using CodeBlocks and GCC compiler. I'd like to use "string safe functions" e.g strlen_s, strcpy_s, but compiler shows an error:
Undefined reference to strlen_s.
I then add a line to the code:
#define __STDC_WANT_LIB_EXT1__ 1
As well as writing the following in the Compiler Options (settings -> compiler -> global compiler settings -> other compiler options):
-std=c11
In the book that I'm reading there's a code to checking whether my compiler supports these functions. The code is as follows:
#include <stdio.h>
int main()
{
#if defined __STDC_WANT_LIB_EXT1__
printf("optional functions are defined");
#else
printf("optional functions are not defined");
#endif
return 0;
}
When I run this code I see "optional functions are defined". I've also reinstalled CodeBlocks but I still get these errors.
Should I install another compiler? If I should, which one will be the best?
#define __STDC_WANT_LIB_EXT1__ 1 is expected to be defined by your application - you have to define it yourself to enable the use of the bounds-checking interface functions.
In order to see if the bounds-checking interface is at all available, you need to check if __STDC_LIB_EXT1__ is defined by the compiler.
Note that no function called strlen_s exists.
This test is not sufficient, you should also test whether the implementation defines the macro __STDC_LIB_EXT1__.
These functions are from a part of the C standard that is called "Annex K" and that is optional. With this macro you test if your C library provides that feature, with the WANT macro defined before any includes you tell the compiler that you want to use these features from Annex K.
Annex K is much controversial, and not many public domain C libraries implement it. Many people think that its interfaces don't provide the security that it claims.
And for the book that you are reading this doesn't seem to be too reliable. But then, I may be biased on that point.
I installed gcc4.9 using the steps mentioned in the SO post here. I was using the latest feature std::exchange() utility function which is introduced in C++14.
#include<list>
#include<utility>
int main() {
std::list<int> lin{5,6,7,8,9};
auto lout = std::exchange(lin, {1,2,3,4});
return 0;
}
I performed following steps to compile the above sample program and got the following compilation error. After sometime I realized that (as there is no warning/hint by compiler message) this feature has been added in the C++14 standard so I need to use -std=c++1y here.
$g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:5:14: error: ‘exchange’ is not a member of ‘std’
auto lout = std::exchange(lin, {1,2,3,4});
^
If we use the C++11 standard feature and does not provide -std=c++11, then GCC gives warning message/hint that your program is using the feature which is introduced in the C++11 as below:
main.cpp:4:21: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11
std::list<int> lin{5,6,7,8,9};
This message is great and lets the user distinguish between the actual compilation error message and not including -std=c++11 option.
However while using gcc4.9 for C++1y feature under -std=c++11, there is no such warning message/hint? I wanted to know what could be the possible reason for this?.
The error/warning about "extended initializer lists" is emitted by the C++ parser. The C++
parser apparently knows how to parse that syntactic construct, understands it and can
provide a sensible error/warning message.
With the function, the situation is a little bit different. The GCC proper does not
contain knowledge about each and every standard function. For some functions it does, but
for most functions it doesn't.
From the compiler proper point of view, std::exchange is just an unknown identifier, the compiler does not contain special knowledge about the standard function std::exchange, and, hence, treats it as any other unknown identifier.
I am trying to use tgamma() from the standard library. When I try to compile, I get the error message:
Call to undefined function tgamma
I have the directive #include <cmath>. I use Embarcadero C++ Builder XE3, which claims to support C++11 standards. What could be my problem, and how to fix it?
Boost contains a tgamma function.
#include <boost/math/special_functions/gamma.hpp>
...
double rootPi = boost::math::tgamma<double>(0.5);
Of course, you can always switch to a different compiler, like gcc.
I have a bunch of compile time asserts, such as:
CASSERT(isTrue) or CASSERT2(isTrue, prefix_)
When compiling with GCC I get many warnings like 'prefix_LineNumber' defined but not used. Is there a way I can hide warnings for compile time asserts? I had no luck searching the GCC documentation. I thought I might have the var automatically used globally inside the same macro but I couldn't think of any way to do it.
Does anyone know of a way to hide that warning in GCC?
Just saw this thread while searching for solutions to this problem. I post here for completeness the solution I found...
The GCC compiler flags that control unused warnings include:
-Wunused-function
-Wunused-label
-Wunused-parameter
-Wunused-value
-Wunused-variable
-Wunused (=all of the above)
Each of these has a corresponding negative form with "no-" inserted after the W which turns off the warning (in case it was turned on by -Wall, for example). Thus, in your case you should use
-Wno-unused-function
Of course this works for the whole code, not just compile-time asserts. For function-specific behaviour, have a look at Function attributes.
Solution for GCC not causing conflicts with other compilers
#ifdef __GNUC__
#define VARIABLE_IS_NOT_USED __attribute__ ((unused))
#else
#define VARIABLE_IS_NOT_USED
#endif
int VARIABLE_IS_NOT_USED your_variable;
This is one of the most anoying warnings, although I undestand that it may useful (sometimes) to check dead code. But I usually have static functions for debugging, or functions that maybe useful sometime in the future, or that are only used temporaly, and I want to keep them in the code.
Fortunately this warning does not care about inline functions.
inline static foo()
{
}
You can create a null statement and cast the result to void. This is portable across compilers, and gcc will not give you any warnings, even with -Wall and -Wextra enabled. For example:
int var; // var is not used
(void)var; // null statement, cast to void -- suppresses warning
A common technique is to create a macro for this:
#define UNUSED(x) ((void)(x))
int var;
UNUSED(var);
#define UNUSED_VAR __attribute__ ((unused))
for any variable just use the above macro before its type for example:
UNUSED_VAR int a = 2;
Wrap this functions by the following directives
All the code that will be placed between push and pop will not warn you about unused functions.
All the rest of the code (outside push and pop) will not be affected.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-function"
... your code
#pragma GCC diagnostic pop
This is hard to answer without knowing the details of your static assert macros. Perhaps you could change to a different macro to avoid this problem? You could either add the 'unused' attribute to the macro as was suggested, or you could use a different form of CASSERT().
Here are descriptions of a few alternatives:
http://www.jaggersoft.com/pubs/CVu11_3.html
http://blog.kowalczyk.info/kb/compile-time-asserts-in-c.html
http://www.pixelbeat.org/programming/gcc/static_assert.html
How about -Wunused-label ?
As of C++ 17 you can use [[maybe_unused]].
For example,
[[maybe_unused]] int foo = 42;
which has the same effect as the old(er) __attribute__((unused)).