Having troubles accessing the filesystem namespace -
Problem:
"Symbol 'filesystem' could not be resolved"`
Leading Research:
How can I get the list of files in a directory using C or C++? - Stack Overflow
C++17 Filesystem - Codingame
Setup:
GCC/G++: 9.2.0
C++: C++17
Demo:
File Demo
#include <iostream>
#include <filesystem>
using namespace std;
namespace fs = std::filesystem;
int main(void) {
return 0;
}
I have tried the std::experimental variant to no success. How can I get C++17 & the <filesystem> API working?
Soln Update:
Thank you P Kramer, w/MSYS2 I was able to quickly come to solution.
Procedure:
Get MSYS2 (msys2-x86_64-20210725.exe)
Run the installer (#loc C:\Sw\msys64)
pacman -Syu
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
Check w/cmd (C:\Sw\msys64\mingw64\bin)
gcc -v (GCC v10.3.0)
Add to path (C:\Sw\msys64\mingw64\bin, C:\Sw\msys64\usr\bin)
Restart Eclipse
Demo compile to confirm C++17 (__cplusplus == 201703L)
Use it!
Final Working Demo
https://gcc.gnu.org/gcc-9/changes.html mentions incomplete filesystem implementation on windows. Goto compiler explorer and compile your sample with gcc 9.2 first. See here : https://godbolt.org/z/q9vTcernn
This will indeed fail, if you change to latest gcc (for windows) everything compiles fine.
So the problem is the compiler version you are using.
Related
I just updated my MacBook Pro to macOS Catalina 10.15, and tried to compile and run a C++ command line program, but I had a problem which didn’t exist on previous versions;
This is simply the code:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, World!\n";
return 0;
}
The code compiles and outputs the expected, but still the Xcode says:
fatal error: 'iostream' file not found
I tried changing the Build Settings/C++ Standard Library to libstdc++, but a warning says:
warning: include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead
And the same iostream error still exists.
I'm compiling from the command line, and none of the answers listed here (or elsewhere) worked for me.
What does seem to work (so far) is to add the following to .profile or whatever script your terminal uses to start up: (zsh, csh, bash, etc.)
export C_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include
export CPLUS_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include
You will probably have to change MacOSX10.15.sdk whenever you upgrade your operating system.
C_INCLUDE_PATH and CPLUS_INCLUDE_PATH are options for the clang toolchain rather than MacOS environment, so hopefully this solution will work long-term, unlike xcode-select --install (which won't fix the include directories on an upgrade) or ln -s ... /usr/include (which is now forbidden by System Integrity Protection).
I had the same problem and used the following youtube video to fix it.
https://www.youtube.com/watch?v=hrPm7tWC-BI&feature=youtu.be
or you can follow this path. Make sure to include the quotation marks
Project - Build Settings - Search Paths - Headers Search Paths, and add the following path:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/"
So, I restarted my laptop and everything seems to be fine right now, thanks for those who tried to help.
libstdc++ is not OK for Xcode Build & Compile time,
libstdc++ is OK for iPhone Run Time
From answer recommended by #Alan Birtles
libstdc++ Support was removed from the iOS 12.0 Simulator runtime, but
it remains in the iOS 12.0 (device) runtime for binary compatibility
with shipping apps.
I encountered this when declaration in .hpp file.
#include <iostream>
#include <string>
OK with
#ifdef __cplusplus
#include <iostream>
#include <string>
// usage code
#endif
I tried a fresh Catalina install with Xcode. I copied and pasted your code into "test.cpp" and then ran:
clang++ test.cpp
in the same directory as the "test.cpp" file from Terminal. The result was an "a.out" file which when run:
./a.out
output the required "Hello, World!" result. Hopefully that is of some use (as a point of reference).
Most probably this is weird, but when I got this error that stoi wasn't declared in this scope, I smiled because I am familiar with this error and it's solution.
I checked this option have g++ follow the c++11 ISO c++ language standard [-std=c++11] in compiler settings of Code Blocks (16.01, with MinGW) and tried recompiling it, but surprisingly it didn't work and the same error persisted. I tried re-installing CodeBlocks but that didn't work.
Also, I tried with windows power shell and command prompt with g++ math_handler.cpp -std=c++11 but got the same error.
What am I doing wrong?
the code is here:
#include<string>
using namespace std;
int main()
{
string body="456";
int i=stoi(body);
}
Note:
I tried with -std=c++0x and g++ too.
the same problem with to_string() function.
gcc version 4.9.2 (tdm -1)
Okay, I found that it is a known bug in MinGW bundled with CodeBlocks. I found the solution here.
Download mingw-to-string-gcc47.zip which contains three patched
header files. (Original patches: wchar.h, stdio.h, os_defines.h)
Copy wchar.h and stdio.h from the include directory in the zip file
to the following directory (overwrite): C:\mingw\include (replace
C:\mingw\ with the appropriate directory)
Copy os_defines.h to the following directory (overwrite):
C:\mingw\lib\gcc\mingw32\4.7.0\include\c++\mingw32\bits (replace
C:\mingw\ with the appropriate directory) (replace 4.7.0 with the
correct version number)
Did you include the required header file?
#include <string>
stoi is also in the std namespace so:
std::stoi()
or:
using namespace std;
I'm using boost library to handle big numbers.
#include <iostream>
#include <boost/multiprecision/cpp_bin_float.hpp>
#include <boost/multiprecision/number.hpp>
namespace mp=boost::multiprecision;
using namespace std;
int main()
{
typedef mp::number<mp::backends::cpp_bin_float<2000> > cpp_bin_float227;
cpp_bin_float227 b = 998;
std::cout << std::numeric_limits<cpp_bin_float227>::digits << std::endl;
cout<<std::setprecision(std::numeric_limits<cpp_bin_float227>::max_digits10)<<pow(b,9999)<<endl;
}
But I got this error at compile-time:
fatal error: boost/multiprecision/cpp_bin_float.hpp: No such file or directory
#include <boost/multiprecision/cpp_bin_float.hpp>
If I use cpp_dec_float instead of cpp_bin_float it works fine.
Why is the library not found and how to fix it?
(I'm using c++11 compiler, in Ubuntu)
SOLUTION:
The problem was that in answe, namely aold version of boost library.
Minimal version to support cpp_bin_float is 1.58
Remove current version with:
apt-get --purge remove libboost-dev libboost-doc
Later I installed version 1.63 (isn't the latest that is 1.64) following
http://www.linuxfromscratch.org/blfs/view/cvs/general/boost.html
That version of boost doesn't have cpp_bin_float. It's also seriously old.
See it live:
boost 1.54 https://wandbox.org/permlink/7MQy5HR90GB0GbVt
boost 1.55 https://wandbox.org/permlink/nPOH5kDRCq1PUXWl
boost 1.56 https://wandbox.org/permlink/IhClSKBx0k0pSVUe OK!
I need to write a program using the (experimental) C++17 filesystem library but clang on my Mac (macOS 10.12.03) doesn't seem to have the filesystem header included.
Since I'm required to use the C++17, I cannot use alternatives like the Boost library.
When I try to compile a sample program that just includes filesystem and iostream (and writes to cout)
#include <filesystem>
#include <iostream>
using namespace std;
int main(){
cout << "test" << endl;
}
I get the following error message:
>clang test.cpp -std=c++1z
test.cpp:2:10: fatal error: 'filesystem' file not found
#include <filesystem>
^
1 error generated.
When I try the same using GCC 6.3 (installed via homebrew) I get:
>gcc-6 test.cpp -std=c++17
test.cpp:2:22: fatal error: filesystem: No such file or directory
#include <filesystem>
^
compilation terminated.
I also tried using experimental/filesystem instead which compiles using gcc but seems to try to compile for iOS leading to another error which seems to be related to iostream
Undefined symbols for architecture x86_64:
"std::ios_base::Init::Init()", referenced from:
__static_initialization_and_destruction_0(int, int) in ccd5QiVt.o
"std::ios_base::Init::~Init()", referenced from:
__static_initialization_and_destruction_0(int, int) in ccd5QiVt.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
The version of my clang is:
>clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I'm grateful for any helpful input since I couldn't find anything that solved my problem so far (although I might have been searching for the wrong terms).
If you need more information I'll gladly provide it but I hope to have included everything.
Libc++, which is the C++ standard library on OS X, has not moved <experimental/filesystem> to <filesystem> yet because the specification is not stable.
Hopefully <filesystem> will be a part of the Clang 6.0 release. (We missed 5.0)
Xcode 11 Beta now includes <filesystem>. Unlike the other answers indicating beta support in Xcode 10, Apple has mentioned this in the release notes.
Also mentioned in the release notes, is this is only supported by iOS 13, macOS 10.15, watchOS 6, and tvOS 13. You will only be able to use std::filesystem for projects targeting these versions or later.
In reply to Max Raskin: I've installed Xcode 10 Beta 4, from July 17, 2018, and this version does not have "#include <experimental/filesystem>" or "#include <filesystem>".
The release notes also do not mention libc++17 <filesystem>. The release notes do mention that the following are in Xcode 10: <any>, <optional>, and <variant>.
Example include file location:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental
EDIT
As mentioned in another answer <filesystem> is available in Xcode 11 Beta according to the release notes:
Clang now supports the C++17 <filesystem> library for iOS 13, macOS
10.15, watchOS 6, and tvOS 13. (50988273)
Here's hoping it's meant to stay this time!
OLD ANSWER
Just checked Xcode 10.2 Beta 4 and it has regular <filesystem>! For the curious, it's in /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/.
EDIT:
Downloaded Xcode 10.2 (10E125) aaaaand ... <filesystem> is gone again. No mention whatsoever in the release notes. If you happen to have an Xcode version that contains <filesystem> lying around (like the Beta 4 I mentioned earlier) copying the file over seems to work okay:
$ sudo cp /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/filesystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/
Mind you, of course, every Xcode update will very likely break this workaround and make another copy necessary. Also, there is probably a good reason why the beta implementation didn't make it into the release. Proceed with caution...
Including gets you the declarations, but to
get the definitions you also have to link with -lstdc++fs (for
libstdc++) or I don't know (for libc++). If someone knows, maybe they
could update this answer?
For libc++ you need to link with -lc++experimental
If anyone still interested, Xcode 10 Beta ships with libc++ that has experimental/filesystem
UPDATE one of Xcode 10 betas used to ship with it, perhaps by accident, Xcode 10.1 unfortunately, doesn't have it :(
I installed XCode 9.4 - no <filesystem>
But Homebrew came to the rescue with LLVM 6
brew update
brew install llvm
And with a change in PATH, I was away.
Recursive directory walk using ftw in c, more details here.
On, -std=c++17 for macOS version 10.xx, filesystem header is not available.
#include <ftw.h>
#include <stdio.h>
#include <sys/stat.h>
#include <string.h>
int list(const char *name, const struct stat *status, int type)
{
if (type == FTW_NS)
{
return 0;
}
if (type == FTW_F)
{
printf("0%3o\t%s\n", status->st_mode&0777, name);
}
if (type == FTW_D && strcmp(".", name) != 0)
{
printf("0%3o\t%s/\n", status->st_mode&0777, name);
}
return 0;
}
int main(int argc, char *argv[])
{
if(argc == 1)
{
ftw(".", list, 1);
}
else
{
ftw(argv[1], list, 1);
}
return 0;
}
output looks like following:
0755 ./Shivaji/
0644 ./Shivaji/20200516_204454.png
0644 ./Shivaji/20200527_160408.png
0644 ./Shivaji/20200527_160352.png
0644 ./Shivaji/20200520_174754.png
0644 ./Shivaji/20200520_180103.png
0755 ./Saif/
0644 ./Saif/Snapchat-1751229005.jpg
0644 ./Saif/Snapchat-1356123194.jpg
0644 ./Saif/Snapchat-613911286.jpg
0644 ./Saif/Snapchat-107742096.jpg
0755 ./Milind/
0644 ./Milind/IMG_1828.JPG
0644 ./Milind/IMG_1839.JPG
0644 ./Milind/IMG_1825.JPG
0644 ./Milind/IMG_1831.JPG
0644 ./Milind/IMG_1840.JPG
I'm experiencing .Call issues when running functions built with Rcpp on Windows, if my c++ code uses C++11 std::regex and I have found no way out so far.
Unlike prior questions on similar issues, I have had neither building nor linking issues. The Rcpp package builds and links fine using the C++11 plugin, making usable packages on my platform. constexpr and C++11-specific functions like std::stoi cause no issue when std::regex is not used.
Using Windows boost libs, I experienced linking issues, even when specifying PKG_LIBS="-L/path/to/boost/libs -lboost_regex", so I'd rather stick to std::regex.
The same packages build, install and run fine under linux, using vanilla std::regex or boost::regex.
I unfortunately found no solution in the fine Rcpp gallery examples.
Windows platform is :
R version 3.2.3 (2015-12-10)
x86_64-w64-mingw32/x64 (64-bit)
Running under:
Windows >= 8 x64 (build 9200)
Rcpp_0.12.3
Rtools 3.3.0.1959 running g++ 4.9.3 (x86_64-posix-seh,
built by MinGW-W64 project), normally C++11-compatible.
PKG_CXXFLAGS="-std=c++11"
The linux platform is similar except for g++ (version 5.3).
Below is a simplified code chunk for duplication.
#include <Rcpp.h>
#if defined(__linux__) && ! defined(FORCE_STL_BUILD)
#include <boost/regex.hpp>
#define reglib boost
#else
#include <regex>
#define reglib std
#endif
#include <string>
using namespace Rcpp;
// [[Rcpp::plugins(cpp11)]]
constexpr int a[3]= {2, 10, 15};
// [[Rcpp::export]]
int my_test(int prop, const std::string& index)
{
#ifndef NO_REG
static const reglib::regex test {"H.*A", reglib::regex::icase};
#endif
int index_int = std::stoi(index) + a[1] + prop;
return index_int;
}
This code runs OK when built using -DNO_REG. Otherwise invoking test::my_test(1, "1000") returns:
`Error in .Call("test_my_test", PACKAGE = "test", prop, index) :
"test_my_test" not available for .Call() for package "test"`
EDIT:
1. The question focuses on std::regex. Boost issues are only incidental comments.
2. Issues only arise after packaging, not using Rcpp::source("cppfile")
3. Packaging code:
R console:
Rcpp::Rcpp.package.skeleton("test", attributes=TRUE, example_code=FALSE, cpp_files="test.cpp")
Rcpp::compileAttributes("test")
CMD console:
REM paths to R/bin/x64 and Rtools/bin, Rtools/mingw_64/bin added to PATH
set PKG_CXXFLAGS=-std=c++11
R CMD build test
R CMD INSTALL test_1.0.tar.gz
ADDITIONAL EDIT:
.Call issues arise as soon as a regex is declared in the C++ code. Using it or no (as in std::regex_match) makes no change.
Can you try disentangling this some more? You are mixing a lot of things here.
Try maybe 'just' C++ from R first, with the newer g++ 4.9.3 compiler and see if that lets you use Boost as you hope. Your use case there is local and non-standard, so you have to work this out. We generally just recommend using BH without linking.
I don't actually see an Rcpp issue here. You are simply pushing the (working, tested, trusted) Rcpp setup into a corner it has not been used in yet. So you may need to work some things out yourself.
Also note that g++ 4.9.3 for R is not really released yet.