QT muggle not able to open file with c++ fstream. Please give me a hand.

[muggleR]

I'm Currently working on project need to read from a file using c++ fstream

---

Environment: Qt version :community 6.3 on windows10

1. this is my resouce editor
   
2. This is the code to open the file

 ifstream reader(":/data/data/Users.txt", ios_base::in);
        if (!reader.is_open())
        {
            cout << "Not able to open Users.txt" << endl;
            exit(2);
        }

and the output

Not able to open Users.txt
Debugging V1.exe has finished with exit code 2.

3. and I got the data.txt path from here
   

I'd appreciate it if you could offer me some advice, many thanks.

[ChrisW67]

You are trying to use a Qt embedded resource from a non-Qt function that is not aware of them. The path provided to the ifstream constructor is being interpreted directly against the Windows file system, and no such file exists. The QFile equivalent knows about the Qt resource system and, when it sees the ":" prefix in the path, switches to looking in the compiled-in resources rather than the host file system.

[JonB]

@muggleR said in QT muggle not able to open file with c++ fstream. Please give me a hand.:

I'm Currently working on project need to read from a file using c++ fstream

@ChrisW67 has explained what the issue is with a resource file path and why ifstream is not going to be able to access it. The question is what you are going to do about it:

• If you do not have a mandatory reason for using a ifstream don't use it! Use the Qt classes instead.
• If you do have to use it (e.g. you are passing this to some library code which demands a ifstream), I have not tested this but: use QFile(":/data/data/Users.txt"), open it, then there is int QFileDevice::handle() const to access the low-level C file handle. I presume there is a C++ function for generating/wrapping a ifstream from/around a file handle? (UPDATE See https://stackoverflow.com/a/5205191/489865 or https://stackoverflow.com/a/5206221/489865 for this?)
• Otherwise you won't be able to use Qt resource paths :( If really necessary you can use Qt calls to copy the file in the resource via its path to a temporary, external file, then that can be opened via a ifstream.

[muggleR]

@ChrisW67 That make sense to me, thanks.

[muggleR]

@JonB Thank you for the reply, I'll consider using QT classes. It seems that using c++ fstream is too treaky in qt system.

[VRonin]

@JonB said in QT muggle not able to open file with c++ fstream. Please give me a hand.:

I have not tested this but: use QFile(":/data/data/Users.txt"), open it, then there is int QFileDevice::handle() const to access the low-level C file handle.

This won't work but it's very close to the solution, you can use QTemporaryFile::createNativeFile to expose a file embedded in the resources to then garb its handle and pass it on to fstream if you need to

[JonB]

@VRonin said in QT muggle not able to open file with c++ fstream. Please give me a hand.:

This won't work but it's very close to the solution, you can use QTemporaryFile::createNativeFile to expose a file embedded in the resources

Is this because QFile(":/...") does not use a genuine file handle in QFile::handle()? I sort of thought it would open a genuine OS file handle into the executable, but does it actually implement it (like reads) via purely in-memory access into the resource area, or what? (You know me: I like explanations, not voodoo! :) )

[ChrisW67]

@JonB Not entirely across the details but a direct memory mapping that could be exposed as-is to non-Qt file processing may be difficult.

Qt rcc considers each resource file individually and will compress any file (variable algorithm) before embedding where the space gain is sufficient. This works very well with things like embedded bulk text, XML, or SVG. When the Qt access paths are used these are decompressed in a manner transparent to the application.

A non-Qt application inspecting the executable content directly will see compressed data. It may be that Qt unpacks into a memory block and then works from that, in which case I guess direct non-Qt access could work.