I'm starting to learn C++20, my first compilable language...
import <iostream>;
int main()
{
int answer {42};
std::cout << "The answer is "
<< answer
<< std::endl;
return 0;
}
When I try to compile the file above, I get an error message due to the compiler not recognizing the statement import <iostream>;, even though I have the newest version of GCC compiler for Ubuntu 20.04.4 LTS.
C++ 20 is considered a new standard (or maybe the latest standard). So most of the compilers do not have full coverage of everything in C++ 20 and the GCC compiler that you are using does not know what is import <iostream> because it does not have full coverage. What you could do, is to check out this list of compilers supporting C++ 20.
Related
Sorry if i ask again about "moudules" in C++.
Im using g++ gcc-c++-12.2.1-4.fc37.x86_64 in fedora 37 linux and vscode.
So i said: i will upgrade my knowladge with the book "A tour of C++ third edition" which its updated to c++20 standard.
The thing that the first program:
import std;
int main()
{
std::cout << "Hello, World!\n";
}
Doesn't compile.
I have enabled "std=c++20" and "-fmodules-ts" and also tried "-std=gnu++20".
The output is this, its like the compiled modules are missing:
std: error: failed to read compiled module: No existe el fichero o el directorio
std: nota: compiled module file is ‘gcm.cache/std.gcm’
std: nota: imports must be built before being imported
std: error fatal: returning to the gate for a mechanical issue
Ok it's in spanish becouse is my native tongue.
Any help?
import std;
This line of code requires not only module support, but also Standard Library Modules (P2465R3 Standard Library Modules std and std.compat) that's part of C++23.
From the Compiler support for C++23 page on cppreference, we can see that it's still not supported by GCC libstdc++.
As OP mentioned that the code snippet is taken from Bjarne's book, I double-checked section 1.2 of it. In the paragraph after the next from the code snippet containing import std;, it's stated that this is not yet standard:
The import directive is new in C++20 and presenting all of the standard library as a module std is not yet standard. [...]
I have a simple program, written in C++, on a Windows 10 machine, compiled with the MinGW g++ compiler.
I am including the <string> header, and it runs fine. When I include the string data type, it will compile, but it will not run.
The minimum amount of code to reproduce this is:
#include <iostream>
#include <string>
using namespace std;
int main() {
string greeting;
cout << "hi" << endl;
return 1;
}
Please note, this works fine:
#include <iostream>
#include <string>
using namespace std;
int main() {
//string greeting;
cout << "hi" << endl;
return 1;
}
The version of the compiler is 6.3.0
g++.exe (MinGW.org GCC-6.3.0-1) 6.3.0
I downloaded it 3 days ago, so I assume it is the most recent version. (Maybe not?)
I have googled and browsed stackoverflow for answers.
The closest question I could find, the person gave up and changed operating systems.
One other solution I found was to use Cygwin's compiler. I would rather not, as I already have a seemingly otherwise fine compiler. It seems that MinGW tools are widely used enough that I should be able to use the compiler.
Any other forum/blog/etc resources have problems about converting strings or calling string methods.
NOTE: The same exact code runs fine on Ubuntu 16.04, with the included compiler.
EDITS:
While I realize that "It does not run" is not helpful, I don't know how else to describe it. I run the compiled program, and it behaves the same as if I entered echo ''. There is no output, no indication that anything has happened. What is the most helpful way to phrase that behavior?
If I use a debugger, I get program exited with code 0xc0000139
A quick google search returns results indication that it is a problem with the compiler. Same as the comments below about my compiler version...
To compile the program, I run g++ main.cpp -o b.exe
To execute it, I run ./b.exe
Mingw has a long standing issue with certain consoles (see their faq). It might be worth checking whether it's failing to output rather than execute by e.g. redirecting to a file ./b.exe >out.txt.
After some useful comments, and much frustration, I decided to try to build the most current compiler. I caved and used Cygwin. (I really have no problem with Cygwin, I just wanted to get MinGW to work.)
I followed this site's instructions (after downloading the current source from https://gcc.gnu.org).
http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/
Notes:
This is for an older version of gcc, but I replaced the appropriate version numbers with 8.2.0 (current at this time).
I was missing some prerequisites, and had to cd into the source directory and run ./contrib/download_prerequisites from the Cygwin terminal. It handled everything seamlessly, and while it took a little bit, I am now able to use string data types and run the program (successfully).
Don't forget the final make install command. I did, and it was a headache.
Lastly, thanks to all the helpful comments, and those that asked for clarification. When I call the mechanic, and say, "my car won't run", they ask helpful questions, and we work together to get them the relevant information they need. That's what happened above, and I learned some things (and solved my issue).
I had the same issue. I downloaded mingw a few days from sourceforge and everything complied fine except when I declared a string. Then it would show no output. Maybe it was some problem with the old version (6.3.0). I deleted all the files and re-installed using the given tutorial : https://code.visualstudio.com/docs/cpp/config-mingw . This is a newer version (8.1.0). Now it works just fine!
Here is my code:
#include <iostream>
#include <iomanip>
#include <complex>
#include <cmath>
int main()
{
using namespace std::complex_literals;
std::cout<< std::fixed<<std::setprecision(1);
std::complex<double> z1= 1i *1i; //imaginary unit squared
std::cout<<"i * i= " <<z1 <<'\n';
std::complex<double> z2=std::pow(1i, 2); //imaginary unit squared
std::cout <<"pow(i,2) =" <<z2 <<'\n';
}
I compile with gcc hello.cpp -lstdc++ -o hello.o
Basically it won't let me double the powers of a complex number when i do std::complex z2=std::pow(1i, 2);..
I get the following error
error: no matching function for call to 'pow(complex int, int)'
std::complex z2=std::pow(1i, 2);
However, if i remove the complex number and do std::complex z2=std::pow(2, 2);
it returns 4, the correct answer..
There are many more lines of compile errors, but i made it brief
This answer follows up the comments to the original question:
you have to force the compiler to use the c++14 standard with the -std=c++14 option because the literal operator""i is part of the C++14 spec.
GCC uses c++14 by default since version 6.1. Check your compiler version with gcc -v and refer to this link for GCC standard support.
EDIT:
I was able to reproduce the compiling issue with GCC 6.3 through the link provided by Mr Richard Critten in the comments to the original question, who was the first to point to the correct answer. My apology because I totally overlooked the reference to the C++14 standard.
Anyway, for the sake of clarity, I'm editing this answer, because I've found something that may be interesting to share.
The reason why compiling with GCC 6.3 fails is the fact that the reference standard has been changed in December 2016 from C++14 to GNU++14, see here.
GNU++14 is an extension to the C++ standard, that, among other things, provides additional functions overload for standard APIs.
I've found that with GNU++14 SFINAE fails in finding a proper overload for the std::pow() functions unless the type is explicitly set in the template call like in the snipped below:
std::complex<double> z2=std::pow<double>(1i, 2);
The GNU++14 includes changes to the cmath and complex header files, that I believe are the cause of the issue.
Turning on the C++14 flag, that is not the default anymore, fixes the problem.
I don't know why it is not compiling on your system, it runs fine on mine.
I think something is wrong with your compiler. And, not the version. yet you could try std::cout << __cplusplus. See what this prints.
C++11 doesn't recognize std::complex_literals, so doubt that is the case, but yet the compiler still couldn't find the function.
I honestly don't understand why it is searching for (complex int, int). The compiler is either corrupt or an old beta version.
You should either download a fresh version of the compiler or run it online somewhere. Try adding -std=c++14, but I doubt that would help.
Try your code here(it works):
https://www.jdoodle.com/online-compiler-c++14
So, I installed Microsoft Visual Studio.. I am using the clang compiler and my program ran smoothly with no errors!
Thanks for all the help guys, but i think clang is a better c++ compiler
When using the #if windows/#if linux compilers features in Debian GCC version 4.7.2, I have been unable to get them work when using std11.
Independently, I can get the compiler to accept the if-defines without complaint. I can also get the compiler to use the same code with c++ 11, without any if-defines (and thus not conditionally). But when I run the conditional defines through the same compiler, with the tag for c++ 11, the code is rejected.
Below I have included a simple example, with two alternate mains, and the error I get. The only difference between the two mains are the commented out lines.
Runs:
g++ main.cpp -std=c++11 -o test
The above uses the c++ 11 standard. When running commented main it works perfectly. But when running uncommented main, it fails entirely, giving the error at the far end of this post.
g++ main.cpp -o test
The above does not use the c++ 11 standard. When running either commented main or uncommented main it works perfectly.
Below are the code examples.
Commented main.cpp:
#include <iostream>
//#if windows
//#include "WindowsSolution.hpp"
//#endif
//#if linux
#include "LinuxSolution.hpp"
//#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
LinuxSolution.hpp:
class LinSolution{
public:
LinSolution(){
}
std::string out(){
std::string ret("Linux solution");
return ret;
}
};
LinSolution myGlobalSolution;
WindowsSolution.hpp:
class WinSolution{
private:
WinSolution(){
}
std::string out(){
std::string ret("Windows solution");
return ret;
}
};
WinSolution myGlobalSolution;
Uncommented main.cpp:
#include <iostream>
#if windows
#include "WindowsSolution.hpp"
#endif
#if linux
#include "LinuxSolution.hpp"
#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
Below is the error I get when compiling with the uncommented main.cpp, using the c++ 11 flag.
main.cpp: In function ‘int main()’:
main.cpp:13:15: error: ‘myGlobalSolution’ was not declared in this scope
The simple constant linux is a GCC extension and not an official OS constant. The proper constant for Debian is probably __gnu_linux__; you can find a list of them for various systems here. Usually official predefined constants follow the convention of using __ at the start.
Your code works without the standard flag because by default GCC compiles in a GNU language mode (GNU C++) rather than a standard language mode (ISO C++); the GNU language includes extensions (extra language features, and in this case, legacy OS constants). When you pass the -std=c++11 flag you are requesting ISO language mode, which means GNU extensions are disabled, including GNU-only constants. To get both GNU extensions and a specific set of ISO features, try requesting a GNU language standard version instead (e.g. -std=gnu++11 works fine).
The following code works fine on Linux but throws an exception on OS X 10.7:
#include <iostream>
#include <locale>
#include <stdexcept>
int main() try {
std::locale::global(std::locale(""));
std::cout << "Using locale: " << std::locale().name() << "\n";
}
catch (std::runtime_error const& e) {
std::cout << e.what() << "\n";
return 1;
}
The output on OS X is:
locale::facet::_S_create_c_locale name not valid
However, the standard explicitly says that
The set of valid string argument values is "C", "", and any implementation-defined values.
So whatever causes the behaviour above is violating the standard.
The compiler used is clang++ 3.1 (tags/Apple/clang-318.0.58); I’ve also tried it with GCC 4.7, installed via Homebrew, with the same result.
Can other people validate this problem? What causes it? Am I doing anything wrong? Is this a bug in OS X?
(Maybe this relates to another xlocale problem but the errors are actually completely different.)
I don't think you're using xlocale. I believe that your problem is with libstdc++, which uses a different locale support library that is not supported on OS X, as the question EitanT links to states.
If you switch to libc++ your program will work.
The poster above it correct...the problem is with libstdc++. I wanted to add my answer because it is not straightforward how to get OS X to link against libc++ and took me over an hour to figure out.
Invoking the compiler/linker by g++ -libstd=libc++ or by clang++ -libstd=libc++ or by the alias c++ -libstd=libc++ will all fail.
The solution for compiling simple programs from the command line instead of messing with the added overhead of Xcode is to allow Xcode to handle the linking by using the command xcrun clang++ -stdlib=libc++
xcrun allows Xcode to manage the tool chain and will build a successful executable where cout.imbue(locale(foo)) will successfully work.