I recently upgraded my OSX to mountain lion and ever since I cannot compile my project using Qt Creator anymore. I get bunch of errors like the following:
/Users/user/codes/lib/io/xdmfWriter.cpp:63: error: explicit instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
/Users/user/codes/lib/io/xdmfWriter.cpp:-1: In instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]':
/Users/user/codes/lib/io/xdmfWriter.cpp:63: instantiated from here
// xdmfWriter.cpp -- line 63:
gridName << xdmfName_ << "." << timeStep;
gridName is a std::ostringstream object and xdmfName_ is a std::string variable declared as a private member of the xdmfWriter class and initialized in the class constructor. I did not have this problem before ... Any ideas?
This can be fixed by adding a c_str() as in:
gridName << xdmfName_.c_str() << "." << timeStep;
However, this is not a permanent solution.
Update: I found the solution in https://web.archive.org/web/20140809210004/http://qt-project.org/forums/viewthread/19106/P15
You need to change -mmacosx-version-min=10.5 in $QTDIR/mkspecs/common/g++-macx.conf to -mmacosx-version-min=10.7.
This is because SDKs for 10.5 or 10.6 are not included in Mountain Lion and XCode 4.4.
I have tried changing the g++-macx.conf fila but I was still getting the errors. I found that using:
QMAKE_CXXFLAGS += -fpermissive
on my pro file did the trick.
Sounds like if I use the Clang toolchain (which forces clang++ instead of llvm-g++) I do not have this problem ...
Related
the following piece of code compiles fine with gcc 11.3.0.
#include <string>
std::string homeName( const std::string& home, std::string surl )
{
if ( surl.find( home ) == 0 )
{
surl.replace( 0, home.size(), "~" ); // shorten url by replacing $HOME with "~"
}
return surl;
}
That is, if a string surl starts with the value of home, replace the head with a tilde, "~".
However, when I switched to gcc 12.2.1, there is a warning (-Wrestrict, included in -Wall) which I do not understand. The warning is for the line with the replace command.
The full message (almost unreadable, as usual) is given below, but first the outcome of some trials: I trimmed the full compiler command to the essential parts.
gcc11 -Wrestrict -O2 -std=c++20 -c file.cpp # Ok, with/without optimisations.
gcc12 -Wrestrict -O2 -std=c++20 -c file.cpp # warning, but not with std=c++17
gcc12 -Wrestrict =O1 -std=c++20 -c file.cpp # Ok
From the manual:
-Wrestrict: Warn when an object referenced by a restrict-qualified parameter (or, in C++, a __restrict-qualified parameter) is aliased by another argument, or when copies between such objects overlap.
However, I do not really understand how this applies to the above piece of code. Can somebody explain what is going on?
Here is some sample output:
[655] build> g++ --version
g++ (SUSE Linux) 12.2.1 20220830 [revision e927d1cf141f221c5a32574bde0913307e140984]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[655] build> g++ -Wrestrict -O2 -std=c++20 -c file.cpp
In file included from /usr/include/c++/12/string:40,
from file.cpp:1:
In static member function ‘static constexpr std::char_traits<char>::char_type* std::char_traits<char>::copy(char_type*, const char_type*, std::size_t)’,
inlined from ‘static constexpr void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’ at /usr/include/c++/12/bits/basic_string.h:423:21,
inlined from ‘static constexpr void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’ at /usr/include/c++/12/bits/basic_string.h:418:7,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits, _Allocator>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’ at /usr/include/c++/12/bits/basic_string.tcc:532:22,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::replace(size_type, size_type, const _CharT*, size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’ at /usr/include/c++/12/bits/basic_string.h:2171:19,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::replace(size_type, size_type, const _CharT*) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’ at /usr/include/c++/12/bits/basic_string.h:2196:22,
inlined from ‘std::string homeName(const std::string&, std::string)’ at file.cpp:7:19:
/usr/include/c++/12/bits/char_traits.h:431:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]
431 | return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
[656] build>
What's going on is an obvious gcc bug. There's nothing wrong with the shown code (except for unrelated bugs mentioned below). The same diagnostic started popping up from my own code, after switching to gcc 12.
I suspect that this specific case is another instance of bug 100366 which first appeared in gcc 11, but seems to have become more widespread in gcc 12 as a result of additional internal compiler optimizations tripping up on it.
The warning seems to be harmless. But it's annoying. So far, with my own code, I've been successful in coming up with tweaks that make it go away. In this case I don't get this warning if I rewrite this to:
if ( surl.find( home ) == 0 )
{
surl="~" + surl.substr(home.size());
}
That is, if a string surl starts with the value of home, replace the
head with a tilde,
If that's the case then the shown code slightly misses the mark. Because if my home directory is /home/sam, this replaces /home/samv/foo with ~v/foo, which is clearly wrong (your original version also suffers the same bug).
So, in addition to fixing the compiler warning you should also think hard what the correct logic should be here, too. It's not as straightforward as it might appear, on the first glance. Filenames are not just random strings. They have structure, and a little bit of organization to them.
Re posted (although not easy to format when some of the g++ output lines seen to be several 100 chars long!).
I have a c++ program that compiles fine on an Ubuntu 12.04 using g++ version 4.6.3. I decided to use a more up to date O/S and g++ - but i'm getting a few strange compile errors. Now I'm using Ubuntu 16.04 and g++ 5.4.0. What is strange is the initial error message I get to .cpp source file does not point to a line of code that should generate that type of message. The errors I see are:
In file included from /usr/include/c++/5/string:52:0,
from pkcs11_test.h:17,
from pkcs11_attr.h:13,
from pkcs11_attr.cpp:16:
/usr/include/c++/5/bits/basic_string.h: In instantiation of ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)
[with _CharT = unsigned char; _Traits = std::char_traits<unsigned char>; _Alloc = sec_allocator<unsigned char>]’:
pkcs11_attr.cpp:48:9: required from here
/usr/include/c++/5/bits/basic_string.h:399:62: error: no matching function for call to
‘std::__cxx11::basic_string<unsigned char, std::char_traits<unsigned char>, sec_allocator<unsigned char>
>::_Alloc_hider::_Alloc_hider(std::__cxx11::basic_string<unsigned char, std::char_traits<unsigned char>,
sec_allocator<unsigned char> >::pointer, const allocator_type&)’
: _M_dataplus(_M_local_data(), __str._M_get_allocator()) // TODO A traits
/usr/include/c++/5/bits/basic_string.h:108:2: note: candidate: std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_Alloc_hider::_Alloc_hider(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::pointer, const _Alloc&) [with
_CharT = unsigned char; _Traits = std::char_traits<unsigned char>; _Alloc = sec_allocator<unsigned char>;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::pointer = unsigned char*]
_Alloc_hider(pointer __dat, const _Alloc& __a = _Alloc())
/usr/include/c++/5/bits/basic_string.h:108:2: note: no known conversion for argument 2 from
‘const allocator_type {aka const std::allocator<unsigned char>}’ to ‘const sec_allocator<unsigned char>&’
/usr/include/c++/5/bits/basic_string.h:106:14: note: candidate: std::__cxx11::basic_string<unsigned char,
std::char_traits<unsigned char>, sec_allocator<unsigned char> >::_Alloc_hider::_Alloc_hider(const
std::__cxx11::basic_string<unsigned char, std::char_traits<unsigned char>, sec_allocator<unsigned char> >::_Alloc_hider&)
struct _Alloc_hider : allocator_type // TODO check __is_final
/usr/include/c++/5/bits/basic_string.h:106:14: note: candidate expects 1 argument, 2 provided
makefile:16: recipe for target 'pkcs11_attr.o' failed
make: *** [pkcs11_attr.o] Error 1
The error message doesn't actually point to sensible line it points to the return statement - as per below.
The code is:
byteString CkAttribute::asByteString () const {
byteString retVal;
if( pValue )
copyCkBStringToBString( (unsigned char *)pValue, ulValueLen, retVal );
// end if
<<<<< error points to the below line>>>>
return retVal;
}
The 12.04 Ubuntu is 32 bit and the new 16.04 Ubuntu is 64 bit. But i have installed g++multilib and tried to compile it with -m32 on the new platform. However, I get the exact same error. The program I'm compiling is quite big and consists of over 12 .cpp source files - all of which compile just fine - it is just this one error in this one source file. It is driving me mad!!
afer installed libcouchbase, I excuted
sudo npm install couchbase
It reported error:
npm WARN cannot run in wd couchbase#1.2.4 (node-gyp rebuild 2> builderror.log) || (exit 0) (wd=/Users/mymac/node_modules/couchbase)
then I went to node_modules/couchbase and executed
npm install
It outputted the log error:
../deps/lcb/src/compat.c:194:36: warning: missing field 'v' initializer [-Wmissing-field-initializers]
struct lcb_create_st cst = { 0 };
^
1 warning generated.
../src/logger.h: In instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]':
../src/logger.h:74: instantiated from here
../src/logger.h:74: error: explicit instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
../src/logger.h: In instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]':
../src/logger.h:74: instantiated from here
../src/logger.h:74: error: explicit instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
../src/logger.h: In instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]':
../src/logger.h:74: instantiated from here
../src/logger.h:74: error: explicit instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
../src/logger.h: In instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]':
../src/logger.h:74: instantiated from here
../src/logger.h:74: error: explicit instantiation of 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
make: *** [Release/obj.target/couchbase_impl/src/couchbase_impl.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:267:23)
gyp ERR! stack at ChildProcess.EventEmitter.emit (events.js:98:17)
gyp ERR! stack at Process.ChildProcess._handle.onexit (child_process.js:807:12)
gyp ERR! System Darwin 12.5.0
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/local/lib/node_modules/couchbase
gyp ERR! node -v v0.10.28
gyp ERR! node-gyp -v v0.13.0
gyp ERR! not ok
It lookes like node-gyp can not compile the source code correctly
if I use the code
var couchbase = require('couchbase');
var db = new couchbase.Connection({
bucket: "default"
},
function(err) {
if (err) throw err;
db.set('testdoc1', {
name: 'Frank1'
}, function(err, result) {
if (err) throw err;
db.get('testdoc1', function(err, result) {
if (err) throw err;
console.log(result.value);
// {name: Frank}
});
});
});
console reports
Users/mymac/node_modules/couchbase/lib/binding.js:17
throw e;
^
Error: dlopen(/Users/mymac/node_modules/couchbase/prebuilt/win/x64/couchbase_impl.node, 1): no suitable image found. Did find:
/Users/mymac/node_modules/couchbase/prebuilt/win/x64/couchbase_impl.node: unknown file type, first eight bytes: 0x4D 0x5A 0x90 0x00 0x03 0x00 0x00 0x00
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at bindings (/Users/mymac/node_modules/couchbase/node_modules/bindings/bindings.js:74:15)
at tryLoadBinding (/Users/mymac/node_modules/couchbase/lib/binding.js:13:31)
at Object.<anonymous> (/Users/mymac/node_modules/couchbase/lib/binding.js:31:17)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
it can not find out the correct couchbase_impl.node(there is nothing)
so it goes to prebuilt and get the wrong platform version
/Users/mymac/node_modules/couchbase/prebuilt/win/x64/couchbase_impl.node
I try to install couchnode on centos, ubuntu, even 1 year before on osx same mac without any problem.
I am not sure if I have changed something/configuration such as gcc to clang when did other job, does it affect this?
I tried
export CC=gcc
export CXX=gcc
export CXXFLAGS=-mmacosx-version-min=10.8
or
export CC=clang
export CXX=clang
export CXXFLAGS=-mmacosx-version-min=10.8
and reinstall couchnode
but none worked
Your comment welcome
had related error: "Error: dlopen([...]/app/node_modules/couchbase/prebuilt/win/x64/couchbase_impl.node, 1): no suitable image found"
I was able to resolve this is on OS X 10.9.5 with xcode 6.0.1
Install a fresh copy of libcouchbase:
$ brew install libcouchbase
This will install libcouchbase into /usr/local/Cellar/libcouchbase/2.4.1 (or whatever version is current).
Next install Node-SDK via npm
$ npm install --couchbase-root=/usr/local/Cellar/libcouchbase/2.4.1 couchbase
looks like you need to declare --couchbase-root= when installing on OS X
When I run project that was created in Linux I get error in the "std::cout<<..." line:
void Assert(bool condition, std::string message)
{
if(!condition)
{
std::cout<<"message"<<message<<std::endl;
int s = 4/0;
}
}
Error message:
/MainData.cpp:159: error: explicit instantiation of 'std::basic_ostream<_CharT,
_Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const
std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits =
std::char_traits<char>, _Alloc = std::allocator<char>]' but no definition available
include lines:
#include"iostream"
#include"vector"
#include "math.h"
#include"cstdlib"
#include "string"
What could be the reason?
It appears this is a MacOS specific quirk, solved by adding the compiler flag -mmacosx-version-min=10.7.
Specifically (as the first link below states), add these two lines to your .pro file:
QMAKE_CFLAGS_X86_64 += -mmacosx-version-min=10.7
QMAKE_CXXFLAGS_X86_64 = $$QMAKE_CFLAGS_X86_64
Supporting links:
Trying to build muParser: error: explicit instantiation of 'std::basic_ostream but no definition available
Mex files on Mountain Lion: explicit instantiation error
I'm in college, and for a project we're using C. We've explored GCC and Clang, and Clang appears to be much more user friendly than GCC. As a result, I'm wondering what the advantages or disadvantages are to using clang, as opposed to GCC, for developing in C and C++ on Linux?
In my case this would be used for student level programs, not production.
If I use Clang, should I debug with GDB and use GNU Make, or use another debugger and make utility?
EDIT:
The gcc guys really improved the diagnosis experience in gcc (ah competition). They created a wiki page to showcase it here. gcc 4.8 now has quite good diagnostics as well (gcc 4.9x added color support). Clang is still in the lead, but the gap is closing.
Original:
For students, I would unconditionally recommend Clang.
The performance in terms of generated code between gcc and Clang is now unclear (though I think that gcc 4.7 still has the lead, I haven't seen conclusive benchmarks yet), but for students to learn it does not really matter anyway.
On the other hand, Clang's extremely clear diagnostics are definitely easier for beginners to interpret.
Consider this simple snippet:
#include <string>
#include <iostream>
struct Student {
std::string surname;
std::string givenname;
}
std::ostream& operator<<(std::ostream& out, Student const& s) {
return out << "{" << s.surname << ", " << s.givenname << "}";
}
int main() {
Student me = { "Doe", "John" };
std::cout << me << "\n";
}
You'll notice right away that the semi-colon is missing after the definition of the Student class, right :) ?
Well, gcc notices it too, after a fashion:
prog.cpp:9: error: expected initializer before ‘&’ token
prog.cpp: In function ‘int main()’:
prog.cpp:15: error: no match for ‘operator<<’ in ‘std::cout << me’
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:112: note: candidates are: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:121: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT, _Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:131: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:169: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:173: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:177: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:97: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:184: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:111: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:195: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:204: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:208: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:213: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:217: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:225: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:229: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:125: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits<char>]
And Clang is not exactly starring here either, but still:
/tmp/webcompile/_25327_1.cc:9:6: error: redefinition of 'ostream' as different kind of symbol
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
In file included from /tmp/webcompile/_25327_1.cc:1:
In file included from /usr/include/c++/4.3/string:49:
In file included from /usr/include/c++/4.3/bits/localefwd.h:47:
/usr/include/c++/4.3/iosfwd:134:33: note: previous definition is here
typedef basic_ostream<char> ostream; ///< #isiosfwd
^
/tmp/webcompile/_25327_1.cc:9:13: error: expected ';' after top level declarator
std::ostream& operator<<(std::ostream& out, Student const& s) {
^
;
2 errors generated.
I purposefully choose an example which triggers an unclear error message (coming from an ambiguity in the grammar) rather than the typical "Oh my god Clang read my mind" examples. Still, we notice that Clang avoids the flood of errors. No need to scare students away.
As of right now, GCC has much better and more complete support for C++11 features than Clang. Also, the code generator for GCC performs better optimisation than the one in Clang (in my experience, I have not seen any exhaustive tests).
On the other hand, Clang often compiles code more quickly than GCC, and produces better error messages when there is something wrong with your code.
The choice of which one to use really depends on what things are important to you. I value C++11 support and code generation quality more than I value convenience of compilation. Because of this, I use GCC. For you, the trade-offs could be different.
I use both because sometimes they give different, useful error messages.
The Python project was able to find and fix a number of small buglets when one of the core developers first tried compiling with clang.
I use both Clang and GCC, I find Clang has some useful warnings, but for my own ray-tracing benchmarks - its consistently 5-15% slower then GCC (take that with grain of salt of course, but attempted to use similar optimization flags for both).
So for now I use Clang static analysis and its warnings with complex macros: (though now GCC's warnings are pretty much as good - gcc4.8 - 4.9).
Some considerations:
Clang has no OpenMP support, only matters if you take advantage of that but since I do, its a limitation for me. (*****)
Cross compilation may not be as well supported (FreeBSD 10 for example still use GCC4.x for ARM), gcc-mingw for example is available on Linux... (YMMV).
Some IDE's don't yet support parsing Clangs output (QtCreator for example *****). EDIT: QtCreator now supports Clang's output
Some aspects of GCC are better documented and since GCC has been around for longer and is widely used, you might find it easier to get help with warnings / error messages.
***** - these areas are in active development and may soon be supported
For student level programs, Clang has the benefit that it is, by default, stricter wrt. the C standard. For example, the following K&R version of Hello World is accepted without warning by GCC, but rejected by Clang with some pretty descriptive error messages:
main()
{
puts("Hello, world!");
}
With GCC, you have to give it -Werror to get it to really make a point about this not being a valid C89 program. Also, you still need to use c99 or gcc -std=c99 to get the C99 language.
I think clang could be an alternative.
GCC and clang have some differences on expressions like a+++++a, and I've got many different answers with my peer who use clang on Mac while I use gcc.
GCC has become the standard, and clang could be an alternative. Because GCC is very stable and clang is still under developing.