I know that std::async is a C++11 thing but I am pretty sure that my compiler has C++11 support.
#include <future>
using namespace::std;
void functionToRun() {
// some code
}
int main() {
auto x = 2; // throws warning warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
std::future<void> metricLoggerFuture = std::async(std::launch::async, functionToRun); // throws error no member named 'async' in namespace 'std'
}
and if I use
std::future<void> metricLoggerFuture = async(std::launch::async, functionToRun); // error: use of undeclared identifier 'async'
Also g++ --version shows
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I have gone through the following,
No member named 'size' in namespace 'std'
No Member named stoi in namespace std
Also,
OS: macOS Catalina
This code is part of a bigger project (wrapper over TigerVNC) so there is a makefile, but since auto complies without any issues I don't think C++11 is the issue and hence passing -std=c++11 in the CXXFLAGS and CPPFLAGS also doen't help.
Looks like you are not compiling with c++11, add -std=c++11 (or later) to your compiler command line or makefile.
Related
Using:
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.1.0
there are huge numbers of errors introduced in the standard library by a really stupid coding error: an example is here:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/chrono:281:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ratio:256:81: fatal error:
unknown class name 'false_type'; did you mean '::std::false_type'?
template struct __is_ratio : false_type {};
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:278:38: note:
'::std::false_type' declared here
typedef _LIBCPP_BOOL_CONSTANT(false) false_type;
^
The compiler diagnostic is correct, it should read ::std::false_type. I fixed that but then found the same error is repeated over and over again all over the library. The library worked until I decided to use chrono. The bug, however, is not just in chrono.
Does anyone know if this has been fixed?
Installed g++ 4.9.0 (experimental) version under Ubuntu (I am using certain features provided by this version)
When building my code, I use cmake from a script, and it builds correctly. gcc below contains the path where g++ is installed (/mnt...)
$_cmake_ $_dir_ -DCMAKE_CXX_COMPILER=${_gpp_} -DCMAKE_C_COMPILER=${_gcc_} -DCMAKE_BUILD_TYPE=${_build_} -DCMAKE_INSTALL_PREFIX=${_install_} -DBUILD_TESTING:BOOL=1
Now, when I make the CppuTest to build the Unit Tests for my code, I get the following error.
make all
compiling UncrosserTest.cpp
In file included from /home/miguel/Desktop/Ugur/scmProject/scm/dist/dev/mfx_prod/scm/20160207/include/scm/services/primitives.hpp:4:0,
from /home/miguel/Desktop/Ugur/scmProject/log/lidya/src/cpp/scm/services/examples/dummy_strategy/Inside.hpp:6,
from AllTests/Uncrosser/UncrosserTest.cpp:7:
/usr/include/c++/4.9/experimental/optional: In member function ‘void std::experimental::_Optional_base<_Tp, _ShouldProvideDestructor>::_M_construct(_Args&& ...)’:
/usr/include/c++/4.9/experimental/optional:294:18: error: expected type-specifier
::new (std::__addressof(this->_M_payload))
^
/usr/include/c++/4.9/experimental/optional:294:18: error: expected ‘)’
/usr/include/c++/4.9/experimental/optional: In member function ‘void std::experimental::_Optional_base<_Tp, false>::_M_construct(_Args&& ...)’:
/usr/include/c++/4.9/experimental/optional:424:18: error: expected type-specifier
::new (std::__addressof(this->_M_payload))
^
/usr/include/c++/4.9/experimental/optional:424:18: error: expected ‘)’
make: *** [objs/AllTests/Uncrosser/UncrosserTest.o] Error 1
In the CppuTest makefile have included CPPUTEST_CPPFLAGS += -std=c++1y. I guess that am missing some flags in this makefile because as I said the C++ experimental library is building correctly in my "regular" code. What am I missing ?
Possible it's an include problem, see CppUTest Manual - section Conflicts with operator new macros (STL!) and Conflicts with my own overload!
TL;DR
In UncrosserTest add includes for CppUTest after your's.
Instead of
#include <CppUTest/TestHarnes.h>
#include "whatever.h"
do
#include "whatever.h"
#include <CppUTest/TestHarnes.h>
I am compiling a project on multiple platforms with the c++0x flag. The only platform I am having trouble on is Mac. It seems to get upset over things that other compilers let slide. I am using Mac 10.8, Qt 5.3.2 with the following version of clang.
clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
This is the error it is generating.
In file included from src/qt/bitcoin.cpp:5:
In file included from ../../Qt5.3.2/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/QApplication:1:
In file included from ../../Qt5.3.2/5.3/clang_64/lib/QtWidgets.framework/Versions/5/Headers/qapplication.h:45:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qcoreapplication.h:45:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qglobal.h:78:
In file included from /Users/user/Qt5.3.2/5.3/clang_64/lib/QtCore.framework/Headers/qcompilerdetection.h:846:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:254:9: error: field has incomplete type 'CScript'
_T2 second;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1994:27: note: in instantiation of template class 'std::__1::pair<const CScriptID, CScript>'
requested here
decltype(__is_constructible_test(declval<_Tp>(), declval<_Args>()...))
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2043:14: note: in instantiation of template class 'std::__1::__is_constructible<false,
std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public __is_constructible<is_scalar<_Tp>::value || is_reference<_Tp>::value,
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2069:14: note: in instantiation of template class
'std::__1::__is_constructible_void_check<false, std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public __is_constructible_void_check<__contains_void<_Tp, _Args...>::value
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2549:34: note: in instantiation of template class
'std::__1::is_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: __is_nothrow_constructible<is_constructible<_Tp, _Args...>::value, _Tp, _Args...>
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2671:14: note: in instantiation of template class
'std::__1::is_nothrow_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> >>' requested here
: public is_nothrow_constructible<_Tp>
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/map:840:13: note: in instantiation of template class
'std::__1::is_nothrow_default_constructible<std::__1::allocator<std::__1::pair<const CScriptID, CScript> > >' requested here
is_nothrow_default_constructible<allocator_type>::value &&
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__config:332:34: note: expanded from macro '_NOEXCEPT_'
# define _NOEXCEPT_(x) noexcept(x)
^
src/keystore.h:43:7: note: in instantiation of exception specification for 'map' requested here
class CBasicKeyStore : public CKeyStore
^
src/serialize.h:28:7: note: forward declaration of 'CScript'
class CScript;
^
src/keystore.h:116:5: note: implicit default constructor for 'CBasicKeyStore' first required here
CCryptoKeyStore() : fUseCrypto(false)
^
I am having the same problem, it seems to be related with clang and c++11.
My scenario:
- Mac osx 10.10.1 yosemite
- Xcode 6.1 with Command Line tools 6.1
- Gnu make 3.81
- gcc -v:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
No homebrew, no macports, just some dependencies compiled by hand.
I am trying to compile for x86_64.
Any clue?
My idea could be recompile every dependency with gcc instead of clang, but I still had not time to test it, maybe it works for you ;)
I built gcc 4.9.0 from source, and was also planning on building clang 3.4.2, however something seems to have gone awry with regards to libstdc++, as the clang build baled pretty quickly with the linker complaining about various undefined references from std.
Indeed, I then tried compiling and linking the trivial program:
#include <iostream>
int main() {
std::cout << 42;
}
and again hit linker errors:
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::cout'
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::ostream::operator<<(int)'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::Init()'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status
(full gcc -v output), both with my freshly-minted gcc 4.9.0 and my Ubuntu's stock gcc 4.6.3.
libstdc++.so exists, in /usr/local/lib64:
ls /usr/local/lib64/libstd*
/usr/local/lib64/libstdc++.a
/usr/local/lib64/libstdc++.so
/usr/local/lib64/libstdc++.so.6.0.20
/usr/local/lib64/libstdc++.la
/usr/local/lib64/libstdc++.so.6
/usr/local/lib64/libstdc++.so.6.0.20-gdb.py
and this directory appears in LIBRARY_PATH and as an -L argument to collect2 in the verbose gcc output.
How do I restore sanity to my system and have the linker find the shared library?
As turns out from your comment, you compiled with gcc rather than g++.
Do not take it as an error, as the compilation went fine! What's showing up is a linker error. Indeed, gcc will tell ld to link against the C standard library rather than the C++ standard one.
To solve, either go for g++ directly or pass -lstdc++.
Turning to Stack Overflow after exhausting all my efforts.
I'm running Code Blocks 13.12 and MinGW 4.8.1 on a Windows 7 OS 64bit system. I spent two days trying to get the compiler to link (statically) to the SFML 2.1 library. I followed both the SFML tutorial and this video tutorial- reinstalling both Code Blocks and MinGW twice before it finally linked.
After that I was relieved that SFML was recognized, but I got 50 errors when I tried to build and run that suggested C++11 features weren't.
Added -std=gnu++11 to compiler options and 13 of those errors went away.
The remaining errors all fall into two categories: mutex is not a member of std and from time t is not a member of chrono::_V2::steady clock. I'm not even sure what _V2 is.
What am I missing?
-------------- Build: Release in PumpTracker2.0 (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -Wall -std=gnu++11 -DSFML_STATIC -O2 -std=gnu++11 -IC:\SFML-2.1\include -IC:\SFML-2.1\include -c C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp -o obj\Release\main.o
In file included from C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:25:0:
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\Account.h:37:1: error: 'mutex' in namespace 'std' does not name a type
std::mutex mu;
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\Account.h:86:22: error: 'to_time_t' is not a member of 'std::chrono::_V2::steady_clock'
time_t currentTp = std::chrono::steady_clock::to_time_t(newly);
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\Account.h:94:48: error: 'from_time_t' is not a member of 'std::chrono::_V2::steady_clock'
std::chrono::steady_clock::time_point tNew = std::chrono::steady_clock::from_time_t(currentTp);
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:51:2: error: 'mutex' is not a member of 'std'
std::mutex mu3;
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:51:13: error: expected ';' before 'mu3'
std::mutex mu3;
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:52:19: error: 'mutex' was not declared in this scope
std::unique_lock<mutex> locker3(mu3, std::defer_lock);
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:52:24: error: template argument 1 is invalid
std::unique_lock<mutex> locker3(mu3, std::defer_lock);
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:52:33: error: invalid type in declaration before '(' token
std::unique_lock<mutex> locker3(mu3, std::defer_lock);
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:214:22: error: 'to_time_t' is not a member of 'std::chrono::_V2::steady_clock'
pS->tpNewest = std::chrono::steady_clock::to_time_t(NextPump);
^
C:\Users\WITcom\Desktop\C++\PumpTracker2.0\main.cpp:245:51: error: 'from_time_t' is not a member of 'std::chrono::_V2::steady_clock'
std::chrono::steady_clock::time_point TT2 = std::chrono::steady_clock::from_time_t(pS->tpNewest);
^
Process terminated with status 1 (0 minute(s), 4 second(s))
37 error(s), 47 warning(s) (0 minute(s), 4 second(s))
As already mentioned the original MinGW distribution is not the best one to go with, if you want to go with up-to-date features. Instead there are projects like Nuwen (Stephan T. Lavavej's website) as well as MinGW Builds that provide MinGW-w64 binaries.
The mentioning of SFML is misleading, since the problems have nothing to do with SFML at all. Keep in mind however that you'll have to rebuild SFML if you change the compiler!
As a next step, it would've been important to post a minimal example of the source code that reproduces the errors, because right now, we can only guess what's going wrong, based on the errors.
If you don't use the GNU extensions explicitly, you should use -std=c++11 instead of -std=gnu++11 and if you look at the build command, you'll notice that it's included twice, which is not necessary.
And now to some guessing about the errors:
Account.h - Make sure the <mutex> header is included.
main.cpp - Make sure the <mutex> header is included.
main.cpp - If std::unique_lock<mutex> is from your code, then you need to add std::, i.e. std::unique_lock<std::mutex>.
main.cpp - time_t things seem to be resolved, but make sure anyways to include <chrono> and <ctime> (since time_t is defined in <ctime>).