Same STL files with different compilers [closed] - c++

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
There are two binary files obtained from the same source file: one compiled with clang++-3.6 and the other one with g++-4.8. In a call to a function from the stl (std::unique, in particular) gdb brings me to the same file: /usr/include/c++/4.8/bits/stl_algo.h.
I expected that the implementations would be different for each compiler though. Do clang and gcc share parts of their C++ implementations?

I expected that the implementations would be different for each compiler though. Do clang and gcc share parts of their C++ implementations?
It's not that they share the same C++ implementations, it is rather that both compilers link with the same standard c++ library by default on your system.
I presume you are on linux, almost all programs installed from package manager link against libstdc++ (provided by g++).
By default, even when compiling with clang++, libstdc++ is used, so when you include iostream for example, it uses the one from /usr/include/c++/4.8.
If you want to link against llvm c++ library, you need to install the "libc++-dev" package (name may vary depending on your distro) and compile using: -stdlib=libc++ (instead of the default: -stdlib=libstdc++).
example:
test.cpp:
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "Hello World!!!\n";
return 0;
}
compiling using:
$ clang++ -stdlib=libc++ -o test test.cpp
will use the header from /usr/include/c++/v1 (from llvm)
but compiling using:
$ clang++ -stdlib=libstdc++ -o test test.cpp
# or (assuming the default on your system is libstdc++)
$ clang++ -o test test.cpp
will use header from /usr/include/c++/4.8 (from g++)

Related

Clang fails to find iostream. What should I do?

Earlier, I posed a related question.
I have the following program extracted from a large project in my Mac OS
#include <iostream>
int main(){
std::cout<<"hello"<<std::endl;
return 0;
}
Compiling it with Clang fails with the following error:
$ clang test.cpp
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
For information,
A) I have already installed xcode command line tools, using xcodeselect --install. But it seems iostream does not locate in the default search path of clang.
B) Using g++ instead of clang compiles the program. But in my problem, I am not allowed to use other compiler than clang, or to change the source program.
C) I can see workaround techniques, e.g, by tweaking the search path in .bashrc or with some symbolic link, etc. But I feel reluctant to use them, because it seems that I have an installation problem with my Clang and tweaking the path only helps to avoid one of these path issues.
clang and clang++ do different things. If you want to compile C++ code, you need to use clang++
Alternatively you can invoke c++ compiler directly by providing language name explicitely:
clang -x=c++

Error with stoi and debugged with gdb [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
My OS is ubuntu 14.04, laptop, i7.
The g++ version is g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2.
I tried to run a simple code to test stoi:
#include <string>
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
When I compile it with: g++ -g prueba2.cpp, I get:
prueba2.cpp: In function ‘int main()’:
prueba2.cpp:6:12: error: ‘stoi’ is not a member of ‘std’
int i = std::stoi(s);
^
When I debug it twice first with g++ -std=c++0x -g prueba2.cpp (I also tried with -std=c++11) and then with dbg, I got:
Then, I also did a simple search and followed the suggestions made in here1, here2 and here3, and none worked.
Am I doing something silly?
Yeah, I think you're doing something pretty silly. You probably compiled the first code, which doesn't have the std::cout statement, and you probably executed the compilation steps without -std=c++11 which would result in std::stoi not being included beecause std::stoi is from C++11 and onward. The result is still the old executable which prints out nothing.
Recompile using -std=c++11 and make sure that you saved your file correctly. Your code clearly works.
Note: the vanilla port of GCC of MinGW on Windows is flawed and has a few bugs related to C++11 and onwards; using MinGW-w64, if you ever decide to compile on Windows, can help the problem.
std::stoi is a C++11 feature. Therefore your code only compiles, if you use the -std=c++11 flags (or the equivalent -std=c++0x flag that you mentioned, which has nothing to do with debugging).
The terminal session you provided also shows that compilation works with those flags and your program runs fine without any problem. If you want to print the parsed result, you can do it like that: std::cout << i << std::endl
If you don't want to use C++11 features, you can use the >> stream operator to parse your string to an int:
stringstream ss(s);
int i;
ss >> n;
But beware: Other than with stoi, you won't get an exception, if your input doesn't contain a valid number. You will have to check the stream's status yourself.

__FILE__ not giving complete file path in 64 bit configuration [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
__FILE__ is returning me the complete file path when I run the program in 32 bit.
But in 64 bit it is giving only the file name. How to resolve this?
That depends probably more on the way you drive your compiler than a 32/64 bits difference.
My expectation (and what I verified just here with gcc) is that __FILE__ gives the name as provided to the compiler. For instance
$ cat foo.c
int main() { printf("%s\n",__FILE__); }
$ gcc foo.c & ./a.out
foo.c
$ gcc ./foo.c & ./a.out
./foo.c
$ gcc `pwd`/foo.c & ./a.out
/the/full/path/as/reported/by/pwd/foo.c
similarly for include files, the path reported is the one used by the compiler to access the header, thus may depend on the way you specified the include directories.

C++11 experimental functions [duplicate]

This question already has answers here:
Why C++11 compiler support still requires a flag?
(2 answers)
Closed 8 years ago.
Every time I use one of the new classes C++11 offers like chrono.h and compile it with GCC it warns me that C++11 functions are still experimental and must be enabled with a special flag to be usable.
Its end 2014 at the moment of writing this, how come that after atleast 3.5 years GCC is still marking C++11 as "experimental" , are, after all those years, some functions that C++11 offers us still not implemented?
If thats the case, how come?
Code :
#include <chrono>
#include <thread>
int main()
{
std::this_thread::sleep_for(std::chrono::milliseconds(3000));
return 0;
}
compiler line :
g++ Source.cpp -o test.exe
GCC version :
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc.
GCC spits out :
C:/Program Files/mingw-w64/x86_64-4.9.2-posix-seh-rt_v3-rev0/mingw64/x86_64-w64- mingw32/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires G compiler and library support for the ISO C++ 2011 standard. This support is curr ently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 comp iler options.
Once I add. '-std=c++11' to the compiler options I no longer get the error/warning message but I was already aware of that. I was puzzled as to why it did give me a warning without adding it. Shouldn't the current std on GCC be C++11 already? Why is this still not the case?
Software and build systems out there use the defaults and expect them to remain fairly stable. GCC does not simply update the default settings every time new standards or features are available.
If you want a particular version of the standard then you should specify it explicitly.

How to compile a C++ program in LLVM using clang++?

There is a tutorial - http://llvm.org/docs/GettingStartedVS.html Example done in pure C. I can compile and link it. Without problem, really. But I need C++, not pure C. And here the difficulties begin.
For clang++ I use string like
"C:\..> clang++ -c hello.cpp -emit-llvm -o hello.bc"
then:
"C:\..> llc -filetype=obj hello.bc"
and
"C:\..> link hello.obj -defaultlib:libcmt -out:hello.exe"
there I get 14 errors LNK2001: unresolved external symbol
So, I need some tips. What I do wrong?
//-----------------
hello.cpp:
#include < iostream >
int main()
{
std::cout << "TEST\n" << std::endl;
return 0;
}
//-----------------
OS: Windows7.
UPD: Main question: how from .bc get .exe? (LLVM, Windows7)
You can use my GCC and Clang packages:
Download and extract them to the same directory. Clang will use GCC 4.6.3's libstdc++ and MinGW-w64's CRT. Call it like you would gcc.
Clang/LLVM cannot currently work with MSVC's C++ library, due to ABI issues. GCC's libstdc++ works quite well, though it has holes in surprising places (like std::to_string, <regex>, and <thread>).
Clang's Windows support is OK, but far from complete. You cannot for example dllexport whole C++ classes, unfortunately. And Win64 code generation is also not good enough to have a working C++ install (even in combination with GCC, like for 32-bit).