I am compiling with g++ 10.2 using -std=c++20 but i get errors like error: ‘atomic_notify_one’ is not a member of ‘std’. I see in the docs that those methods are supported in c++20. Do i miss something?
As far as I understand neither g++-10.2 nor g++-10.3 does not support atomic_notify_one. However, here the trunk version of the compiler (in which __cplusplus is equal to 202002), as well as my local unstable version of the compiler g++-11.0 (in which __cplusplus is also equal to 202002) perfectly cope with the functions atomic_notify_one, atomic::notify_one
And BTW, unfortunately I did not find official support information. In some places it is introduced in g++-10, in some it is still not implemented yet. Cppreference says it is implemented in g++-11, so I guess it is. In general I would not rush to use atomic_notify_one in production
Related
The error that is being generated is below.
error: 'size' was not declared in this scope
When I use nums.size(), it is working fine. It could be because of using an older compiler version, but in my system when I check the version it shows 10.3.0, which I think is the latest version. How do I fix this?
The std::size function was added in C++17, therefore, you need to enable its support. With GCC, just add -std=c++17 as a command-line argument to your g++ call.
You can also check the libstdc++ source code: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/range_access.h#L236. As you can see, there is an #ifdef that makes std::size available only if C++17 (or higher standard) support is applied.
I just tried compiling code that I wrote a while ago using Gnu g++ in C++11 mode, to see if the code will need reworking anytime soon (I also plan to test it in C++17 mode for the same reason).
I found that the kill() function caused a compiler error and it seems that the kill function no longer exists in the signal.h header.
I just looked at http://www.cplusplus.com/reference/csignal/ as a reference which seems to confirm this is not just a Gnu-specific omission, but seems to be in the standard.
I can't find a rationale for this omission anywhere, nor can I find any proposal for how I should manage processes without it. Can anyone point me in the right direction?
C++ standard function is raise.
kill is a POSIX function that requires POSIX process id pid_t, none of which is required in C++ standard.
OK, I was too quick to post that question, of course fork/kill etc are not part of the C++ standard in the first place but are common additions on unix-like platforms.
My real problem was that I used the wrong compiler switch. For anyone else hitting this problem, to get strict C++11 standard, use:
g++ -std=c++11
But to get the C++11 standard plus non-standard extensions use:
g++ -std=gnu++11
Using the latter, I can build and call fork/kill no problem.
this line of code isn't compiling for me on GCC 4.2.2
m_Pout->m_R[i][j] = MIN(MAX(unsigned short(m_Pin->m_R[i][j]), 0), ((1 << 15) - 1));
error: expected primary-expression before ‘unsigned’
however if I add braces to (unsigned short) it works fine.
can you please explain what type of casting (allocation) is being done here?
why isn't the lexical parser/compiler is able to understand this c++ code in GCC?
Can you suggest a "better" way to write this code? supporting GCC 4.2.2 (no c++11, and cross platform)
unsigned short(m_Pin->m_R[i][j]) is a declaration with initialisation of an anonymous temporary, and that cannot be part of an expression.
(unsigned short)(m_Pin->m_R[i][j]) is a cast, and is an expression.
So (1) cannot be used as an argument for MAX, but (2) can be.
I think Bathsheba's answer is at least misleading. short(m_Pin->m_R[i][j]) is a cast. Why is it that the extra unsigned messing things up? It's because unsigned short is not a simple-type-specifier. The cast syntax T(E) works only if T is a single token, and unsigned short is two tokens.
Other types which are spelled with more than one token are char* and int const, and therefore these are also not valid casts: char*(0) and int const(0).
With static_cast<>, the < > are balanced so the type can be named with a sequence of identifiers, even static_cast<int const*const>(0)
You could use the §2 in Bathsheba's answer but it is more idiomatic to use static_cast in C++:
static_cast<unsigned short>(m_Pin->m_R[i][j])
BTW, your error is not related to GCC. You'll get the same if using Clang/LLVM or any (C++99 or C++11) standard conforming C++ compiler.
But independently of that, you should use a much newer version of GCC. In july 2015 the current version is GCC 5.1 and your GCC 4.2.2 version is from 2007, which is very ancient.
Using a more recent version of GCC is worthwhile because:
it enables you to stick to a more recent version of C++, e.g. C++11 (compile with -std=c++11 or -std=gnu++11)
recent GCC have improved their diagnostics. Compiling with -Wall -Wextra will help a lot.
recent GCC are optimizing better, and you'll get more performance from your code
recent GCC have a better and more standard conforming standard C++ library
recent GCC are better for debugging (with a recent GDB), and have sanitizer options (-fsanitize=address, -fsanitize=undefined, other -fsanitize=.... options) which help finding bugs
recent GCC are more standard conforming
recent GCC are customizable thru plugins, including MELT
older GCC 4.2 is no more supported by the FSF, and you'll need to pay big bucks the few companies supporting them.
You don't need any root access to compile from its source code a GCC 5 compiler (or cross-compiler). Read the installation procedures. You'll build a GCC tailored to your particular libc (and you might even use musl-libc if you wanted to ....), perhaps by compiling outside of the source tree after having configured with a command like
...your-path-to/gcc-5/configure --prefix=$HOME/soft/ --program-suffix=-mine
then make then make install then add $HOME/soft/bin/ to your PATH and use gcc-mine and g++-mine
I've just updated MinGW using mingw-get-setup and i'm unable to build anyting that contains <cmath> header if I use anything larger than -O0 with -std=c++1y. (I also tried c++11 and c++98) I'm getting errors like this one:
g++.exe -pedantic-errors -pedantic -Wextra -Wall -std=c++1y -O3 -c Z:\Projects\C++\L6\src\events.cpp -o obj\src\events.o
In file included from z:\lander\mingw\lib\gcc\mingw32\4.8.1\include\c++\cmath:44:0,
from Z:\Projects\C++\L6\src\utils.h:4,
from Z:\Projects\C++\L6\src\events.cpp:10:
z:\lander\mingw\include\math.h: In function 'float hypotf(float, float)':
z:\lander\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
{ return (float)(_hypot (x, y)); }
Is something wrong on my side?
Or version at mingw repo is bugged? And if so, is there any quick fix for this header?
To avoid any further speculation, and downright bad suggestions such as using #if 0, let me give an authoritative answer, from the perspective of a MinGW project contributor.
Yes, the MinGW.org implementation of include/math.h does have a bug in its inline implementation of hypotf (float, float); the bug is triggered when compiling C++, with the affected header included (as it is when cmath is included), and any compiler option which causes __STRICT_ANSI__ to become defined is specified, (as is the case for those -std=c... options noted by the OP). The appropriate solution is not to occlude part of the math.h file, with #if 0 or otherwise, but to correct the broken inline implementation of hypotf (float, float); simply removing the spurious leading underscore from the inline reference to _hypot (float, float), where its return value is cast to the float return type should suffice.
Alternatively, substituting an equivalent -std=gnu... for -std=c... in the compiler options should circumvent the bug, and may offer a suitable workaround.
FWIW, I'm not entirely happy with MinGW.org's current implementation of hypotl (long double, long double) either; correcting both issues is on my punch list for the next release of the MinGW runtime, but ATM, I have little time to devote to preparing this.
Update
This bug is no longer present in the current release of the MinGW.org runtime library (currently mingwrt-3.22.4, but fixed since release 3.22). If you are using anything older than this, (including any of the critically broken 4.x releases), you should upgrade.
As noted by Keith, this is a bug in the MinGW.org header.
As an alternative to editing the MinGW.org header, you can use MinGW-w64, which provides everything MinGW.org provides, and a whole lot more.
For a list of differences between the runtimes, see this wiki page.
MinGW uses gcc and the Microsoft runtime library. Microsoft's implementation support C90, but its support for later versions of the C standard (C99 and C11) is very poor.
The hypot function (along with hypotf and hypotl) was added in C99.
If you're getting this error with a program that calls hypot, such as:
#include <cmath>
int main() {
std::cout << std::hypot(3.0, 4.0)) << '\n';
}
then it's just a limitation of the Microsoft runtime library, and therefore of MinGW. If it occurs with any program that has #include <cmath>, then it's a bug, perhaps a configuration error, in MinGW.
I am porting a project from Windows to Linux/Ubuntu, which involves using open software called "PST SDK"
(http://pstsdk.codeplex.com) written in c++. This has not been updated since 2010 but it works fine in
Windows and supposedly works/did work in Linux. I set up a demo program with nothing more than including
the header files (the library is all headers, nothing to link). I had a lot of errors but got them
fixed by using g++ instead of gcc, and fiddling with the location of the library files and required
boost files.
However once I tried making some calls, I ran into problems. I got a few things working, but the
following code:
std::vector<pstsdk::folder> folderlist;
folderlist.push_back(folder);
causes this compile error:
error: 'pstsdk::property_bag& pstsdk::property_bag::operator=(const pstsdk::property_bag&)' is private
(There is a lot of other veribiage about what was instantiated from what file). Here is the compile command:
g++ -c -I/usr/local/include -Iboost_1_46_1 -Ipstsdk -I/usr/local/include/mysql ostdemo.cpp
It is specifically the push_back call causing the errors - take that out and they go away. Of course
that is critical to the working of my program. Any idea what this could be? I assume it has
something to do with my compiler version or switches, but I can't figure it out. I am not much of
a c++ programmer so any help would be appreciated.
Your vector::push_back() requires that the type is copy-assignable. Obviously, your pstsdk::folder is not copy-assignable due to the assignment operator being private.
What are the requirements for a type to be placed in a vector? It depends on whether you're using pre-C++11 or C++11, plus what operations you plan to do on these types. See here:
http://en.cppreference.com/w/cpp/container/vector
Pay attention to CopyAssignable, CopyConstructible, MoveAssignable and MoveConstructible
So the case of it working with Windows as opposed to Linux:
Remember that "Windows" and "Linux" are not C++ compilers. You need to expand on this and tell us what version of the g++ compiler you're using on each OS.