clang's support of C++ 11 lambda - c++

I have this C++ 11 code that uses lambda, this is an example.
#include <iostream>
using namespace std;
int main()
{
auto func = [] () { cout << "Hello world"; };
func(); // now call the function
}
When I compiled this code with clang 3.1 (Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)), I got this error
lambda.cpp:7:17: error: expected expression
auto func = [] () { cout << "Hello world"; };
What might be wrong? In this site, lambda seems to be supported with clang 3.1.
ADDED
With -std=gnu++11 or c++11 option, I got these error messages.
0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.7.4 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name lambda.cpp -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 128.2 -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/clang-module-cache -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir /Users/smcho/Desktop/C++test -ferror-limit 19 -fmessage-length 173 -stack-protector 1 -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-XvZzHg.o -x c++ lambda.cpp
1. lambda.cpp:7:49: current parser token ';'
2. lambda.cpp:6:1: parsing function body 'main'
3. lambda.cpp:6:1: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal 2 (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://developer.apple.com/bugreporter/ and include command line arguments and all diagnostic information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-roTwCZ.ii
clang: note: diagnostic msg: /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-roTwCZ.sh

This is because clang++ by default compiles your code using ISO C++ 1998 standard (including the defects addressed in the ISO C++ 2003 standard) except for 'export' (which has been removed in C++11)
Lambdas are part of Clang's C++11 Language Extension, therefore you need to compile your code with -std=c++11 or -std=gnu++11
Also see: Clang 3.1 and C++11 support status and Activating C++11 support in Clang
EDIT: I think you are trying to compile your program with the C compiler (clang) rather than C++ compiler (clang++) or your installation of Clang doesn't link to libc or libstdc++. Try to link against each library to see which one works for you, it is possible that libc might not be installed on your system.
Try to compile your program with C++11 mode using the clang++ executable (the C++ compiler) and link it either with Clang C++ Standard Library or the GNU Standard C++ Library
1)
# Uses Clang C++ Library and enables C++11 mode
clang++ -stdlib=libc++ -std=c++11 [input]
2)
# Uses GNU Standard C++ Library and enables C++11 mode
clang++ -stdlib=libstdc++ -std=c++11 [input]
Another possible problem might be that you haven't compiled Clang with the right options to enable C++11 language extensions, try and check the documentation for correct flags to use when you configure the compilation process for Clang.

The Xcode is updated using AppStore, but it still crashes on my Mac (Lion 10.7.5)
I could download the macport to compile the example successfully.
sudo port install clang-3.1
clang++-mp-3.1 -std=c++11 lambda.cpp

Responding to the newly edited post:
I investigated this issue a bit, and it's a bug that was corrected in release versions of clang 3.1. I'm currently using:
Debian clang version 3.1-3eudoxos1 (branches/release_31) (based on LLVM 3.1)
However when I tested with clang 3.0-6ubuntu3 I get a similar error to the one you posted.
Because your version is marked from SVN I assume that your issue is that it's from the prerelease versions of 3.1 and lambda support hadn't been fully implemented yet.
I can confirm that lambdas do work in clang because I'm working on a project that uses them and we target both clang and gcc. There are a few compiler boogs that crop up from time to time; however, nothing as simple as your given example, of course.
So, my recommendation is to update your version of clang.

I needed to install command line tools as is this post explains - Does Xcode 4.4 come with subversion?

Related

c++11 warning on MacOS [duplicate]

This question already has answers here:
Compile C++11 code on mac?
(4 answers)
Closed last year.
I have clang 13.0.0 on my Mac. I'm trying to compile some .cpp files using the command
g++ file.cpp -o file
But I get this warning message:
file.cpp:23:26: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
for (const double &e : timestamp) outFile << std::setprecision(10) << e << "\n";
On the clang documentation is said that c++11 is supported by clang 13. On my terminal running man clang I find: The default C++ language standard is gnu++14.
Typing g++ -v I get:
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 13.0.0 (clang-1300.0.29.3)
Target: arm64-apple-darwin21.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Why am I getting this warning?
AppleClang defaults to c++98, whereas llvm-clang defaults to the later gnu++14; to access the c++11 implementation, you must add the flag, --std=c++11 or --std=c++14. cf. https://opensource.apple.com/source/clang/clang-703.0.29/src/tools/clang/www/cxx_status.html
If you are expecting the gnu g++, it must be installed separately, because on macOS g++ aliases to clang, which is the Apple fork of clang known as AppleClang.
If you were expecting llvm-clang, that also must be separately installed. AppleClang 13 ≠ llvm-clang 13.

Why does MinGW GCC tolerate missing return types even with `-pedantic-errors`, unlike regular GCC?

Here's the code:
main() {}
On gcc.godbolt.org, both GCC 10.1 and Clang 10 (with -Wall -Wextra -pedantic-errors -std=c++20) refuse to compile this.
GCC: error: ISO C++ forbids declaration of 'main' with no type [-Wpedantic]
Clang: error: C++ requires a type specifier for all declarations
But on my local machine, MinGW GCC happily accepts this code without any errors or warnings (with the same flags). This is not something new; this specific peculiarity was there for years.
Why does MinGW GCC behave differntly from the regular GCC in this case? Are there any flags to make it diagnose this error?
I got my GCC from MSYS2. It identifies as
# g++ --version
g++.exe (Rev3, Built by MSYS2 project) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
Clang 10 on the same machine does reject the code (the official binary, using libstdc++ from this GCC).
As noted by #ssbssa, MinGW GCC enables -fms-extensions by default, and it's one of the effects of that flag.
Compile with -fno-ms-extensions to fix that.

clang seems to use the gcc libraries

This is the first time I use clang. What I notices is that any error from clang referencing the std library looks like this:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/ostream:245:7:
^^^ ^^^ ^^^
So it looks like clang links — or at least includes — the gcc libraries.
The command I used: clang++ -c -Wall -Wextra -Werror -g test.cpp -o test.o. (The program had a intentional error just to prove this).
How is this possible? What can I do to make clang use its own libraries (but not break gcc)?
Additional information:
I am on a Ubuntu 14.04 machine.
clang++ --version
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
Target: x86_64-pc-linux-gnu
Thread model: posix
g++ --version
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
I had previously installed several versions (at the same time, used them with update-alternatives) of gcc with apt-get. Right now I have only 4.8 (I have uninstalled the others). Could I have messed up something then? I have never installed clang (I guess it is default with Ubuntu).
Just to clarify: the correct programs compile and run in clang++.
Further tests: I know that gcc didn’t implement yet types like is_trivially_constructible and move operations on iostream in their standard c++11 library (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html) and that clang has full c++11 conforming library so I tested those compiling with clang and I got the corresponding gcc errors, which only confirms that clang is using gcc libraries.
A very basic program
#include <iostream>
using namespace std;
int main() {
cout << "Yada Yada" << endl;
return 0;
}
gives this error when compiling with -std=c++1y in clang++:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/iostream:39:
...
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace
using ::gets;
~~^
So right now I can’t compile anything with c++1y in clang.
You need to install libc++ and make clang use it with -stdlib=libc++
I had similar issue: GCC (g++) already was installed on my LinuxMint (Ubuntu base) so when compile with clang, was getting an " error: no member named 'gets' in the global namespace using ::gets ".
resolved by installing libc++-dev (sudo apt-get install libc++-dev) and compiling with -stdlib++ (clang++ -g -std=c++1y -stdlib=libc++ helloworld.cpp -o helloworld)
Your real problem is that you're using C++14 (c++1y was the informal name used to refer to it when it wasn't yet fully formed), with a C++ library belonging to GCC 4.8. GCC 4.8 has complete C++11 support, but hardly even started on C++14 features.
This is caused by C++14 removing std::gets, and the GNU C library anticipating on that by not defining gets in the global namespace while the C++ library has not yet caught up and is trying to make it available in the std namespace.
The proper way to solve this does not require using libc++, just to use a C++ library with C++14 support. GLIBCXX 4.9 (aka libstdc++) already suffices.

The command line clang/clang++ doesn't work on MacBook Air 2012 Mid with OS X 10.8.5

Originally, I used clang++ with -std=c++11 compile my C++11 code, everything was OK. Recently, I updated the Xcode in AppStore, I compiled the SAME program in command line again, it doesn't work anymore, it shows errors like below:
/usr/include/c++/4.2.1/bits/stl_construct.h:81:38: error: no matching
constructor for initialization of
'std::basic_string'
::new(static_cast(__p)) T1(_value);
It seems the clang++ is using gcc's header files, apparently, gcc's version is very old. However, if I compile the same program by using Xcode, everything is fine.
It seems, at command line , the clang++ can't find the correct header files anymore.
More information, running command clang++ --version, following output:
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0 Thread model: posix
which clang++
/usr/bin/clang++
RESOLVED with option -stdlib=libc++

error : BOOST DISABLE THREADS

i have some problem with my boost library. i m using freebsd and installed my boost using ports. Boost version is : 1.45 and i use g++47 as compiler. Also i have never defined BOOST DISABLE THREADS at there : /usr/local/include/boost/config/user.hpp .Also exactly my error is :
/usr/local/include/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
explicitly but where ?? And my compile command;
g++47 -O3 -Wall -std=c++0x -I. -Iinclude -I../include -I/usr/local/include -c -o Application.o src/Application.cpp
Thanks
The experimental GCC version 4.7 disables Boost.Threads. See: https://svn.boost.org/trac/boost/ticket/6165
Edit: It should be noted that as of the release version of GCC 4.7, and Boost higher than 1.48 (Boost_1_48_0 is still not working), threads works again.
See the ticket 6165 mentioned above by Joachim:
To define 'threads' support, GCC <= 4.6 defines _GLIBCXX__PTHREADSwhereas GCC >= 4.7 defines _GLIBCXX_HAS_GTHREADS. So, in order to compile older Boosts using any GCC more recent than 4.6 you need the patch libstdcpp3.hpp.patch enclosed in that ticket.
Another problem that could also prevent Boost on working with modern compiler is ticket 6940 (TIME_UTC has a special meanhing in C11, therefore Boost >= 1.50 use TIME_UTC_ instead)