I am compiling the code on solaris 5.11.
G++ version is 4.8.2.
The same code works on Ubuntu but gives the error: 'to_string() was not declared in this scope' on solaris.
I went through many links and tried the following things:
Adding 'std::' before to_string(). This gives error - 'to_string is not a member of std'
Added 'std=c++11' or 'std=c++0x' while compilation.
Both the above things do not work.
Is there anything related to Solaris?
The actual code was very huge. So simulating the error in sample code below.
temp.cpp
#include<iostream>
#include<string>
using namespace std;
int main()
{
string str;
int i = 10;
str = "john age is " + to_string(i);
cout << str;
return 0;
}
command: g++ temp.cpp -std=c++0x -o temp
For GCC 4.8.2 the to_string functions are defined conditionally, according to the following:
#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
&& !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))
The GLIBCXX_USE_C99 macro depends on a large number of C99 functions being supported by the OS, so presumably the necessary C99 library functions were not found when building GCC on Solaris. So the to_string definitions are absent.
In current versions of GCC the condition is more fine-grained, and checks whether the C99 functions are defined in C++98 mode and C++11, so that the absence of any C99 function doesn't disable everything:
#if __cplusplus >= 201103L
//...
#if _GLIBCXX_USE_C99_STDIO
It's not possible to backport these improvements to GCC 4.8, so you might need to update to at least GCC 6.
compile using std=c++11 as below
g++ -std=c++11 filename.cc
Note : your compiler must support c++11
Related
I'm trying to learn new features/gimmicks of c++17, but then I got to std::byte and for some unknown reason I can't seem to be able to compile even most basic "hello world" type program with the type.
entire program:
#include <cstddef>
int main(int argc, char* argv[])
{
std::byte byte;
return 0;
}
compilation command:
g++ ./main.cpp
But the output is always:
./main.cpp: In function ‘int main(int, char**)’:
./main.cpp:4:10: error: ‘byte’ is not a member of ‘std’
std::byte byte;
I work on Ubuntu 18.04 with gcc 7.4.0. I have checked "/usr/include/c++/7.4.0/" and header file cstddef is there and byte seems to be defined.
I have also tried to use clang:
clang++ ./main.cpp
But the result was same. At this point I can only think that cstddef is corrupted/bugged. Are there any solutions to this?
As πάντα ῥεῖ pointed out in comment I was missing c++17 compile flag. Right compilation command:
g++ -std=c++17 ./main.cpp
If you use clang 5.0 (even with -std=c++17 flag) the same error occur.
In that case, to solve this you need to upgrade to clang 6.
A temporay and quick workaround is possible (but not recommanded since it plays with std namespace), it could be something like:
#if defined(__clang__) && __cplusplus >= 201703L && __clang_major__ < 6
// This is a minimal workaround for clang 5.0 with missing std::byte type
namespace std {
enum class byte : unsigned char {};
}
#endif
When I run this code on ideone.com, it prints (2,3):
#include <iostream>
#include <complex>
int main() {
std::complex<double> val = 2 + 3i;
std::cout << val << std::endl;
return 0;
}
But when I use clang on macOS 10.11.6, I get no errors or warnings, but the output is (2,0):
$ clang --version
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
$ clang -lc++ test.cpp && ./a.out
(2,0)
What happened to the imaginary part? Am I doing something wrong?
I believe for this first example the compiler is using a GNU extension:
-fext-numeric-literals (C++ and Objective-C++ only)
Accept imaginary, fixed-point, or machine-defined literal number
suffixes as GNU extensions. When this option is turned off these
suffixes are treated as C++11 user-defined literal numeric suffixes.
This is on by default for all pre-C++11 dialects and all GNU dialects:
-std=c++98, -std=gnu++98, -std=gnu++11, -std=gnu++14. This option is off by default for ISO C++11 onwards (-std=c++11, ...).
When I run it with clang I get (are you using -Wall -pedantic? :)):
warning: imaginary constants are a GNU extension
[-Wgnu-imaginary-constant]
Either way, your code is not standard compliant. To use C++14 literals make the code:
#include <iostream>
#include <complex>
using namespace std::complex_literals;
int main() {
std::complex<double> val = 2.0 + 3i;
std::cout << val << std::endl;
return 0;
}
From the documentation:
These operators are declared in the namespace
std::literals::complex_literals, where both literals and
complex_literals are inline namespaces. Access to these operators can
be gained with using namespace std::literals, using namespace
std::complex_literals, and using namespace
std::literals::complex_literals.
Using gcc (4.7.2 here) I get warnings about unused auto variables, but not about other variables:
// cvars.h
#ifndef CVARS_H_
#define CVARS_H_
const auto const_auto = "const_auto";
const char const_char_array[] = "const_char_array";
const char * const_char_star = "const_char_star";
const char use_me = 'u';
#endif // CVARS_H_
//---
//comp_unit.cpp
#include "cvars.h"
void somef()
{
//const_auto // commented out - unused
use_me; // not using any of the others either
}
// compile with $ g++ -std=c++11 -Wunused-variable -c comp_unit.cpp
// gcc outputs warning: ‘cvars::const_auto’ defined but not used [-Wunused-variable]
// but does not complain about the other variables
Is this an inconsistency in GCC?
1.1 If so, what should happen in all cases, warning or no warning?
1.2 If not, what is the reason for the difference in behavior?
Note: Concerning 1.1, I imagine no warning should be printed in this case (this is what clang does). Otherwise, any compilation unit including a constant-defining header but not using all the constants within would contain lots of warnings.
These warnings are entirely up to the implementation, so there is no "should". But, yes, I agree: constants would ideally not generate these warnings even when declared using auto.
Since I can reproduce your observation in GCC 4.7 and GCC 4.8.0, but not in GCC 4.8.1 or 4.9, I'd say the guys over at GNU would agree too. In fact, I believe you're seeing bug 57183.
I've been learning C++ and using the Terminal for the last couple of months. My code was compiling and running fine using g++ and C++11, but in the last couple of days it started giving errors and I have had problems compiling since. The only programs I can compile and run depend on older C++ standards.
The errors I first got related to #include < array > in the header file. Not sure why this happened, but I got around it by using boost/array instead. Another error I can't solve is with std::stoi. Both array and stoi should be in the C++11 standard library. I made the following simple code to demonstrate what's going on:
//
// stoi_test.cpp
//
// Created by ecg
//
#include <iostream>
#include <string> // stoi should be in here
int main() {
std::string test = "12345";
int myint = std::stoi(test); // using stoi, specifying in standard library
std::cout << myint << '\n'; // printing the integer
return(0);
}
Try to compile using ecg$ g++ -o stoi_trial stoi_trial.cpp -std=c++11
array.cpp:13:22: error: no member named 'stoi' in namespace 'std'; did you mean
'atoi'?
int myint = std::stoi(test);
~~~~~^~~~
atoi
/usr/include/stdlib.h:149:6: note: 'atoi' declared here
int atoi(const char *);
^
array.cpp:13:27: error: no viable conversion from 'std::string' (aka
'basic_string') to 'const char *'
int myint = std::stoi(test);
^~~~
/usr/include/stdlib.h:149:23: note: passing argument to parameter here
int atoi(const char *);
^
2 errors generated.
I also get these errors at compilation when using gcc or clang++ and with -std=gnu++11 (I guess they all depend on the same file structure). I also get the same error whether I specify std:: in the code, or if I specify using namespace std;
I worry that these issues arose because of the September Command Line Tools update via Xcode or because I installed boost and this somehow messed up my C++11 libraries. Hopefully there is a simple solution.
My system:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-> dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
Thanks for any insight you can offer.
clang has a weird stdlib, you need to add the following flag when you compile
-stdlib=libc++
your snippet works on my mac with
g++ -std=gnu++11 -stdlib=libc++ test.cpp -o test
This answer describes the problem
Here is the code: error shows up for line 8 of main.hpp .
//main.hpp
#ifndef MAIN_HPP // if main.hpp hasn't been included yet...
#define MAIN_HPP // #define this so the compiler knows it has been included
#include <array> // OFFENDING LINE 8
using std:array
class Quicksort {
public:
void sort(array);
};
#endif
This header is being used by this c++ file.
#include "main.hpp"
// this is just the start of a quicksort algorithm, base case only
void Quicksort::sort (array list) {
if (list.size == 1 || list.size == 0) {
return;
}
}
Why am I getting this error? I thought my C++ and g++ were fine. Any other reasons it might not be working?
I'm compiling with the command (on Mac, with newest X-Code): g++ version 4.2
g++ -Wall -c quicksort.cpp
When I use -std=c++11 it says:
unrecognized command line option "-std=c++11"
You need C++11 support to be able to include <array>. On GCC you would need to use the -std=c++0x flag (or -std=c++11 on the latest versions).
Furthermore, array lives in the std namespace, and you probably mean to pass a reference:
void sort(std::array&);
If your compiler does not support the relevant parts of C++11, you can use the version from TR1:
#include <tr1/array>
...
std::tr1::array<int, 5> a = ...;
You forgot to include -std=c++11 or -std=gnu++11 (-std=c++0x and -std=gnu++0x on older versions of GCC before 4.7.0), the latter which includes extensions. If that still doesn't work then you need a more recent version of GCC.