I tried to yield current thread:
std::this_thread::yield();
But unfortunately GCC knows better:
'yield' is not a member of 'std::this_thread'
Have I forgotten about some hack similar to D_GLIBCXX_USE_NANOSLEEP, or what?
Yes, this appears to be an issue similar to the one with _GLIBCXX_USE_NANOSLEEP. GCC has yield conditionally compiled depending on the macro _GLIBCXX_USE_SCHED_YIELD. It should compile if you define that.
This will be fixed as of GCC 4.8.
You shouldn't define _GLIBCXX_USE_NANOSLEEP or _GLIBCXX_USE_SCHED_YIELD in your code. They are GCC/libstdc++-internal macros, so that's what should define it. If they aren't defined, it's because GCC wasn't configured with the option to check for availability of the functions. Since there are apparently no downsides to enabling that option for whatever system it is you're using, you could ask whoever provides your GCC to do so. Until that's done, a safer hack than enabling the macro in your code is to modify the c++config.h file on your system to define the macros.
You may need to use '--enable-libstdcxx-time' when configuring gcc to enable detection of sched_yield. For some reason, there is a single check for multiple features
Related
I'm working on a multi-platform codebase, and on one of the platforms, sprintf_s isn't available, but snprintf does exist, so in this case the solution is to have the line
#define sprintf_s snprintf
However, I'd like to either automatically revert this (or throw a compile time error so I can do it manually) should the platform implement sprintf_s.
I've found multiple questions here to detect if a class has a member function defined (or an overload exists of a stream operator), but none for a function like sprintf_s.
(I'd rather not use anything experimental, but if std::experimental::is_detected is the only solution so be it).
The ideal solution looks something like
if !sprintf exists
#define sprintf_s snprintf
but something like the following would also be acceptable
static_assert(!sprintf_s_exists, "sprintf_s is now defined");
An implementation that provides sprintf_s() should define the macro __STDC_LIB_EXT1__ in <stdio.h>. You might also define __STDC_WANT_LIB_EXT1__ to 1 before including the header yourself.
You can also check for implementations you are sure support it, such as MSVC with a minimum version number, and enable it conditionally only for those.
The more general appriach is what auticonf traditionally did: attempt to compile a small program that calls the function you're testing for, and check the return value. If the program compiles and runs as expected, the script added a macro such as HAS_SPRINTF_S to the configuration file, and the program could then test for that.
Such problem (speaking generally) is not uncommon. Many systems solve it during configure phase of the build (when generating platform specific make or ninja files). There you would normally provide the build system generator with a small "feature test" app which would either compile fine or fail to compile, and you can base the logic of the build system (usually by having it define required compiler macros) based on either of outcomes.
In CMake something similar to the above is called cmake-compile-features
I want to find out storage type of variables in a function block. How to check if compiler has elevated auto variable storage to register storage or if variables declared with register storage are honored by compiler? I am assuming by seeing the assembly code of the obj file after optimization would give us an idea. Please list the switch that I need to use with gcc or cl.exe to get this information?
The -S switch in gcc is the one you are looking for.
See ยง3.2 Options Controlling the Kind of Output (GCC manual)
You can look at the generated assembly, but there's no way to programmatically determine this from within your program. Generally be aware that GCC ignores the register keyword except to issue errors if you try to take the address of a register-storage variable, and when used in common with GCC-specific extensions to force a variable into a particular register for use in conjunction with inline asm. No idea what MSVC does.
I'm getting this warning on a stack variable:
warning: object.member may be used uninitialized in this function
In this case I do not wish to force initialization to just to get rid of the warning as it consumes CPU cycles. The variable is a POD structure so a memset on it is not zero cost. I can verify that the variable is never used uninitialized, so I'd just like to suppress the warning for it.
In general I do want the warning, just not on this particular variable in this particular scenario. How can I suppress the warning?
Looks like the pragma diagnostics are the correct way to go but they require quite a recent version of GCC (4.6)
No acceptable solution prior that version is known.
Try doing this:
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
This pragma comes in three interesting and helpful flavors : warning, error, ignored. See 6.56.10 Diagnostic Pragmas for their usages. The link says,
GCC allows the user to selectively
enable or disable certain types of
diagnostics, and change the kind of
the diagnostic. For example, a
project's policy might require that
all sources compile with -Werror but
certain files might have exceptions
allowing specific types of warnings.
Or, a project might selectively enable
diagnostics and treat them as errors
depending on which preprocessor macros
are defined.
The accepted answer has two big problems that requires more than a comment.
First, it deactivates the warning for the whole file. If that pragma resides in a header, probably for more. Warnings are useful and if it is indeed a false positive, one should disable the warning for a bunch of code as small as possible.
Then the warning in the OP is "maybe uninitialized" which is deactivated by -Wmaybe-uninitialized, as opposed to -Wuninitialized.
#pragma GCC diagnostic push // save the actual diag context
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized" // disable maybe warnings
function() or int variable; // impacted section of code
#pragma GCC diagnostic pop // restore previous diag context
GCC differentiates between uninitalised and self initalized, e.g. compiling:
int main() {
int i = i;
return i;
}
With gcc -Wall -Wextra gives no warnings, unless you explicitly added -Winit-self as well, yet it gets completely optimized out by my quick testing.
#Nawaz has answered the question as specifically asked, but have you considered that the fact that you need this may indicate you're declaring your struct too early/at a less nested scope than appropriate? It would generally be much preferred if you could declare your struct at a point where you can actually initialize it rather than declaring it earlier and filling it in various locations.
Also, even though you can verify that it's never used uninitialized right now, what if someone else adds a new code path in the future and it's not initialized properly? If you disable the warning then it'll silently compile and probably break in an unexpected way. Unless you can prove that the initialization is taking a measurable amount of your program's CPU it's probably better to just do the initialization up front.
Selectively disable GCC warnings for only part of a translation unit?
Is there Q_OBSOLETE or Q_DEPRECATED in C++ with Qt 4.7?
Or is there a similar C++ macro or keyword?
If you use Q_DECL_DEPRECATED you should get the outcome you are looking for e.g.:
Q_DECL_DEPRECATED void foo();
Pull the real function out of public scope.
Create another function with the same name in public scope.
Insert your warning/fail code in that function.
Call the original with the new.
Just use the
#warning
directive
although is not C++ standard is quite unlikely you will encounter a compiler that does not support it (see this SO question).
You might want to do something similiar yourself:
#ifdef Q_TREAT_OBSOLETE_AS_ERRORS
#define Q_OBSOLETE(X) \
BOOST_STATIC_ASSERT(false); \
X
#else
#define Q_OBSOLETE(X) X
#endif
This construction simply substitutes some deprecated code / part of code if there is no Q_TREAT_OBSOLETE_AS_ERRORS defined and generates compilation-time error otherwise.
Note that BOOST_STATIC_ASSERT has no scope limitations, so does the Q_OBSOLETE macro.
Probably this is not the best way to solve your problem and actually I'm not sure this is useful.
You might just mark the code as #obsolete or simply point it out in the comments.
By "deprecated constructs", you really mean "deprecated member functions". You're asking for a compile-time warning to draw your attention to the call site of any deprecated function.
This isn't possible in any reasonable way in standard C++, and I don't see any attributes in G++ that would support this either. Qt can't really add a feature like that if the compiler doesn't have some support for it already.
However, Microsoft Visual C++ supports an __declspec(deprecated) extension, and I would imagine it's possible to write a compiler plugin for G++ 4.5 that adds a similar feature.
I have been testing inline function calls in C++.
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
Stroustrup in The C++ Programming language wirtes:
The inline specifier is a hint to the compiler that it should attempt to generate code [...] inline rather than laying down the code for the function once and then calling through the usual function call mechanism.
However, I have found out that the generated code is simply not inline. There is a CALL instrction for the isquare function.
Why is this happening? How can I use inline functions then?
EDIT: The command line options used:
**** Build of configuration Debug for project InlineCpp ****
**** Internal Builder is used for build ****
g++ -O0 -g3 -Wall -c -fmessage-length=0 -osrc\InlineCpp.o ..\src\InlineCpp.cpp
g++ -oInlineCpp.exe src\InlineCpp.o
Like Michael Kohne mentioned, the inline keyword is always a hint, and GCC in the case of your function decided not to inline it.
Since you are using Gcc you can force inline with the __attribute((always_inline)).
Example:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
Source:GCC inline docs
There is no generic C++ way to FORCE the compiler to create inline functions. Note the word 'hint' in the text you quoted - the compiler is not obliged to listen to you.
If you really, absolutely have to make something be in-line, you'll need a compiler specific keyword, OR you'll need to use macros instead of functions.
EDIT: njsf gives the proper gcc keyword in his response.
Are you looking at a debug build (optimizations disabled)? Compilers usually disable inlining in "debug" builds because they make debugging harder.
In any case, the inline specified is indeed a hint. The compiler is not required to inline the function. There are a number of reasons why any compiler might decide to ignore an inline hint:
A compiler might be simple, and not support inlining
A compiler might use an internal algorithm to decide on what to inline and ignore the hints.
(sometimes, the compiler can do a better job than you can possibly do at choosing what to inline, especially in complex architectures like IA64)
A compiler might use its own heuristics to decide that despite the hint, inlining will not improve performance
Inline is nothing more than a suggestion to the compiler that, if it's possible to inline this function then the compiler should consider doing so. Some functions it will inline automatically because they are so simple, and other functions that you suggest it inlines it won't because they are to complex.
Also, I noticed that you are doing a debug build. I don't actually know, but it's possible that the compiler disables inlining for debug builds because it makes things difficult for the debugger...
It is a hint and the complier can choice to ignore the hint. I think I read some where that GCC generally ignore it. I remeber hearing there was a flag but it still does not work in 100% of cases. (I have not found a link yet).
Flag: -finline-functions is turned on at -O3 optimisation level.
Whether to inline is up to the compiler. Is it free to ignore the inline hint. Some compilers have a specific keyword (like __forceinline in VC++) but even with such a keyword virtual calls to virtual member functions will not be inlined.
I faced similar problems and found that it only works if the inline function is written in a header file.