Based on the response to Size of file using C++17, I wrote the following program. But, when the executable is run, I get a segmentation fault. I am using g++ 8.3.0 on an iMac running High Sierra.
// c17filesize.cpp
// Jul-02-2019
#include <cstring>
#include <filesystem>
using namespace std;
int main(int argc, char **argv)
{
char filename[100];
(argc > 1) ? strcpy(filename, argv[1]) : strcpy(filename, __FILE__);
auto size = filesystem::file_size(filename);
}
Prefer using string (and its contructor) over c style strings.
according https://en.cppreference.com/w/cpp/filesystem/file_size you must specify full path. Did you verify argv[1] holds a full path?
check the file exist before attempting to read its size std::filesystem::exists(filename);
use try and catch sections to catch an exception.
Just bumped into segfault whilst using std::filesystem:exists.
With GCC 8.3. Had to link with -lstdc++fs to solve the problem.
Note: GCC 9+ solves this problem (https://gcc.gnu.org/gcc-9/changes.html)
Compiling with gcc 9.1.0 went through successfully without any qualms.
Related
I am trying to do some very fast conversions in C++ and charconv seems the way to go since it uses a very low level logic. The problem is that when I try to include this header and then call, say, std::to_chars(...), neither the header is found nor std has a 'to_chars' member. I updated and reinstalled gcc but this problem is still there. Now I have seen some threads that say that I should update somehow libc++17 but they are not very specific about what I should do, as things are a bit different for MacOS.
Some code to illustrate the library and it's use:
#include <iostream>
#include <typeinfo>
#include <charconv> //error: 'charconv' file not found
struct to_chars_result{
char *str;
std::errc err;
};
int main(int argc, const char * argv[]) {
std::string str("12Test");
auto result = std::to_chars(str.data(), str.data()+str.size(), 12345); //No
//member named 'to_chars' in namespace 'std'.
return 0;
}
As for gcc -v command output:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin14.4.0/5.1.0/lto-
wrapper
Ziel: x86_64-apple-darwin14.4.0
Konfiguriert mit: ../gcc-5.1.0/configure --enable-languages=c++,fortran
Thread-Modell: posix
gcc-Version 5.1.0 (GCC)
Any help appreciated!
gcc 5.1 was released on April 22, 2015.
The paper that added to_chars to the C++17 standard was written in 2016.
Why do you expect that gcc5 will have implemented it?
[ Later: That was the paper that added the <charconv> header, too ]
I'm specifically building a test program to work on Chaiscript, which is how I encountered this issue:
chai.cpp:
#include <cstdio>
#include <iostream>
#include <chaiscript/chaiscript.hpp>
#include <chaiscript/chaiscript_stdlib.hpp>
std::string helloWorld(const std::string &t_name)
{
return "Hello " + t_name + "!";
}
int main(int argc, char** argv, char** env) {
chaiscript::ChaiScript chai;
chai.add(chaiscript::fun(&helloWorld), "helloWorld");
chai.eval("puts(helloWorld(\"Bob\"));");
return 0L;
}
/usr/lib/gcc/i686-pc-cygwin/5.4.0/../../../../i686-pc-cygwin/bin/as: CMakeFiles/chai.dir/src/chai.cpp.o: too many sections (37830)
/tmp/ccqGbeku.s: Assembler messages:
/tmp/ccqGbeku.s: Fatal error: can't write CMakeFiles/chai.dir/src/chai.cpp.o: File too big
/usr/lib/gcc/i686-pc-cygwin/5.4.0/../../../../i686-pc-cygwin/bin/as: CMakeFiles/chai.dir/src/chai.cpp.o: too many sections (37830)
This issue doesn't appear when I build on Mac or Linux.
I discovered a workaround to this issue from the Chaiscript CMakeLists.txt:
if(MINGW OR CYGWIN)
add_definitions(-O3)
endif()
Other searches on the Internet imply this big-object problem is linked the Windows executable format, and is not likely to be addressed in G++. Using MingW32 did not address this error in my case - I'm not going to 64-bit.
Object file has too many sections
Hi I am new to C++ and Code::Block
I am trying to make a simple code to test it, using strings.
when I compile the code there is no problem, but when I try to debug it, Code::Block gives me the following warning:
Cannot open file:
File:../../../../../src/gcc-4.9.2/libgcc/unwind-sjlj.c
Info: "Multiple information windows with the same message have been
supressed."
Image of the error FYI:
Part of the code that gives me an error.
inside main function
#include <iostream>
#include <string>
int main ()
{
std::mystring("What's wrong with strings");
return 0;
}
I realise that this error only occurs when I try to debug a string or a file containing a string.
Any help would be appreciated.
some other information that might help:
Code::Block 16.01
Compiler MinGW gcc4.9.2
Windows 7 Professional 32 bits SP1
First of all, to use strings you must include the file header string. And the name of the type string is..std::string, not std::mystring.
#include <string>
int main(int argc, char** argv)
{
std::string mystring("Nothing's wrong with strings");
return 0;
}
#include <iostream>
using namespace std;
int main ()
{
string mystring = "Whats wrong with my string";
return 0;
}
If you write it in the following way, it should work.
It's safer to define strings like I showed it. It will be also easier for you if you add using namespace std in the beginning of every program if you are new to C++.
I installed Netbeans and as C++ compiler I installed cygwin. I made a simple project to test out my installation, this is the code:
#include <cstdlib>
#include <iostream>
using namespace std;
int main(int argc, char** argv) {
cout << "test";
return 0;
}
This is the error message that it gives: http://pastebin.com/jRRh7MPi
I hope you guys can help me out.
You need to either explicitly link to C++ standard library, or compile using g++ instead of gcc.
I know there's been a handful of questions regarding std::ifstream::open(), but the answers didn't solve my problem. Most of them were specific to Win32, and I'm using SDL, not touching any OS-specific functionality (...that's not wrapped up into SDL).
The problem is: std::ifstream::open() doesn't seem to work anymore since I've switched from Dev-C++ to Code::Blocks (I've been using the same MinGW-GCC back-end with both), and from Windows XP to Vista. (It also works perfectly with OS X / xcode (GCC back-end).)
My project links against a static library which #includes <string>, <iostream>, <fstream> and <cassert>, then a call is made to functionality defined in the static library, which in turn calls std::ifstream::open() (this time, directly). Following this, the stream evaluates to false (with both the implicit bool conversion operator and the good() method).
Code:
#include "myStaticLibrary.hpp"
int main(int argc, char **argv)
{
std::string filename("D:/My projects/Test/test.cfg");
std::cout << "opening '" << filename << "'..." << std::endl;
bool success(false);
// call to functionality in the static library
{
std::ifstream infile(filename.c_str());
success = infile.good();
// ...
}
// success == false;
// ...
return 0;
}
stdcout.txt says:
opening 'D:/My projects/Test/test.cfg'...
When I open stdcout.txt, and copy-paste the path with the filename into Start menu / Run, the file is opened as should be (I'm not entirely sure how much of diagnostic value this is though; also, the address is converted to the following format: file:///D:/My%20projects/test/test.cfg).
I've also tried substituting '/'s with the double backslash escape sequence (again, slashes worked fine before), but the result was the same.
It is a debug version, but I'm using the whole, absolute path taken from main()'s argv[0].
Where am I going wrong and what do I need to do to fix it?
Please create a minimal set that recreates the problem. For example, in your code above there's parsing of argv and string concatentation, which do not seem like a necessary part of the question. A minimal set would help you (and us) see exactly what's going wrong, and not be distracted by questions like "what's GetPath()?".
Try to do this instead of assert(infile.good()):
assert(infile);
I have overseen the importance of the fact that the function in question has close()d the stream without checking if it is_open().
The fact that it will set the stream's fail_bit (causing it to evaluate to false) was entirely new to me (it's not that it's an excuse), and I still don't understand why did this code work before.
Anyway, the c++ reference is quite clear on it; the problem is now solved.
The following code:
#include <string>
#include <iostream>
#include <fstream>
#include <assert.h>
using namespace std;;
int main(int argc, char **argv)
{
std::string filename("D:/My projects/Test/test.cfg");
std::cout << "opening '" << filename << "'..." << std::endl;
std::ifstream infile(filename.c_str());
assert(infile.good()); // fails
return 0;
}
works fine on my Windows system using MinGW g++ 4.4.0, if I create the required directory structure. Does the file test.cfg actually exist? If you are opening a stream for input, it wioll fail if the file is not there.
Edit: To remove any DevC++ to CB issues:
build using command line only
make sure you rebuild the static library too