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 9 years ago.
Improve this question
i am new to c++ 11 . so i wore a small code using c++ 11 feature . but the compiler issues no type found error while using auto . my compiler is updated and i use osx mavericks
here's my code :
#include<iostream>
#include<vector>
using namespace std;
int main()
{
vector<int> v(100);
for(int i=0;i<100;i++)
{
v[i]=i;
}
for(auto p=v.begin();p!=v.end();p++)
cout<<*p<<'\t';
cout<<endl;
return 0;
}
You will need to pass the -std=c++11 flag to your compiler or -std=c++0x depending on your compiler version.
If you're using gcc 4.2, chances are it doesn't have C++0x support yet.
See this page.
This answer might be of some use to you.
GCC 4.2 is ancient, but Apple don't ship a newer version.
You can either install a modern GCC from somewhere like Mac Ports
(which is probably simpler and quicker) or build it yourself following
the instructions at http://gcc.gnu.org/wiki/InstallingGCC
Related
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++)
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.
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.
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 8 years ago.
Improve this question
I am trying to use Intel TBB in a segment of Xeon Phi offload code. The code fails to compile with error error : *MIC* cannot open source file "tbb\parallel_for.h"
I have the MPSS stack installed, I ran the binutils.msi utility, and my includes at the top of the offloaded code file is as follows:
#include <offload.h>
#pragma offload_attribute(push, target(mic))
#include <tbb\parallel_for.h>
#pragma offload_attribute(pop)
//other includes and code follows
Why does this fail?
What do I need to change to offload and run my code sucessfully?
EDIT :
After adding the -tbb option to the "Additional Options for MIC Offload Compiler" the compiler has found the <tbb\parallel_for.h> file however it gives several warnings and errors about tbb library code not being marked shared. follows is my offloaded code segment.
#pragma offload target(mic:0) in(nums) out(results)
tbb::parallel_for<int>(0,ARRAY_SIZE,1,[&](int i)
{
results[i] = findZero(nums[i]);
});
The offload compiler basically consists of two (very) different compilers called separately on the same code. Each of them generally has its own command line, include, and library paths; and not all the command line options translated from host to the MIC compiler. In case of TBB, compiler has special option /Qtbb or just -tbb which takes care of all the paths for both compilers.
Please refer to tbb\examples\GettingStarted\SUB_STRING_FINDER\sub_string_finder_extended.cpp for how to use TBB from offload region. And check out the Makefile for how to build the example.
In order to run the code from MSVC environment, you need to setup the same environment as for Intel Compiler used to build the GettingStarted\Sub_string_finder example. The easy way to duplicate the environment inside MSVC is to run it from the same console window where the example works:
devenv /useenv
Or specifically, you need to set the MIC_LD_LIBRARY_PATH environment variable to point to MIC TBB binaries as shown here for other libraries.
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 7 years ago.
Improve this question
So I've been cutting my teeth on another coding project, and figured that the best thing that I could try is to port RetroArch all in one Emulator into Native Client, so that it could very well be a packaged app with cloud saves entirely within a browser. Look up the project on Github since I don't have enough links.
The way RetroArch is built on linux is to run a configure script, then make, then sudo make install. Altering the configure agent to select the Native Client compilers, I was able to get a couple seconds into the build when this happened,
http://pastebin.com/0WtrY6aU
using this custom Makefile here.
http://pastebin.com/iv6RmQVr
I figure it's gonna be a long hard road building and debugging this puppy, but where do you recommend I get started?
You're starting from a good place, you've just hit your first compile error.
Here it is:
In file included from settings.c:23:
input/input_common.h:73: error: redefinition of typedef ‘rarch_joypad_driver_t’
driver.h:327: note: previous declaration of ‘rarch_joypad_driver_t’ was here
Here is an excerpt from input_common.h:
typedef struct rarch_joypad_driver
{
...
} rarch_joypad_driver_t;
Here is an excerpt from driver.h:
typedef struct rarch_joypad_driver rarch_joypad_driver_t;
Just as the error says, the typedef is being redefined. I ran a test using gcc 4.6.3 from Ubuntu 12.04:
typedef struct foo { int bar; } foo_t;
typedef struct foo foo_t;
int main() { return 0; }
This compiles and links fine. The same code compiled with x86_64-nacl-gcc (which is using gcc 4.4.3), gives the following error:
typedef.c:2: error: redefinition of typedef ‘foo_t’
typedef.c:1: note: previous declaration of ‘foo_t’ was here
It seems that this error has been relaxed in more recent versions of gcc. I did some searching and found this stackoverflow link: Why "Redefinition of typedef" error with GCC 4.3 but not GCC 4.6?.
It's worth noting that x86_64-nacl-g++ will compile this code unmodified. Here are two things to try:
Compile with CC using x86_64-nacl-g++ instead of x86_64-nacl-gcc
ifdef out the definition in driver.h, and replace the other use in that file with struct rarch_joypad_driver.
For #2, you can use the following:
#ifndef __native_client__
...
#endif
Good luck, there likely will be more compile failures to fix. :)