I write
FILE * new_file = fopen("Penguins.jpg","rb");
I fully confident that file exist and it is in right directory. I also tried a lot of various modes like "rb+" "r". I also chanded path like fopen("C:\Penguins.jpg","rb"); Compilator always says :
Besides, openCV open the file. But i need in FILE*. What wrong?
In order to denote a special character within a string, it must be preceded with a backslash.
Since the backslash itself is also a special character, it must be preceded with yet another backslash.
So change this:
fopen("C:\Penguins.jpg","rb");
To this:
fopen("C:\\Penguins.jpg","rb");
Please note that you need to apply this only for strings that are part of the code, i.e., strings that are "treated" by the compiler, not by the preprocessor (such as names of included header files, for example).
According to the documentation of fopen from http://www.cplusplus.com/reference/cstdio/fopen/
The file opens successfully is the function returns a non-null pointer:
If the file is successfully opened, the function returns a pointer to a FILE object that can be used to identify the stream on future operations.
Otherwise, a null pointer is returned.
So because your variable new_file (not new_file->_ptr) is valid, the file should be opened.
Related
For example, suppose we have a file called "Hello.txt", then checking if "hello.txt" or "heLLo.txt" exist should both return true.
If you're running Windows or any case-insensitive filesystem, then there's nothing to do but check one casing. If "Hello.txt" exists, then "hEllo.txt" exists (and is the same file) (the difficult problem here is when you want to make sure that the file is spelled with a given casing in the filesystem)
If you're running a case-sensitive filesystem, just take directory name of the current file, list file contents, and compare entries against the current filename, ignoring case.
Take a look at fcaseopen, which demonstrates how to handle case insensitive file operations.
Essentially, the C headers/functions to use are:
From dirent.h, use opendir/readdir/closedir to go thru the files in a directory
From string.h, use strcasecmp to compare two filesnames, ignoring the case of the characters
I am trying to run a program called Geant4, and I have this make file containing numerous .cc files involved in the program, but when I run it I get this error:
/Volumes/Silviu/Geant4/geant4.10.02.p02/examples/basic/B1/src/._B1PrimaryGeneratorAction.cc:1:4096: error:
source file is not valid UTF-8
I am not sure how to provide more details, but the point is that I have a file called B1PrimaryGeneratorAction.cc, but I am not sure what the error means, or what ._B1PrimaryGeneratorAction.cc actually represent. And what is a not valit UTF-8? Can anyone help please?
Inspect the "._B1PrimaryGeneratorAction.cc" file reported there. The name seems suspicious, maybe you extracted an archive incorrectly thus having a broken source file.
Also the position info ":1:4096" is kind of suspicious - it says that the invalid character is the 4096th character on the first line. Sounds like a corrupted file to me, just check that file contents (C++ source files usually do not have 4096 characters on a single line, although there can be exceptions indeed).
As far as I can tell, this might be the correct contents of the file:
http://geant4.web.cern.ch/geant4/UserDocumentation/Doxygen/examples_doc/html/B1PrimaryGeneratorAction_8cc_source.html
(and that file does not seem to contain any "strange" non-ASCII characters)
Using windows xp, i want to read a value from .ini file.
The value is a path.
Using QSettings, the result of the call to "settings.value("key").toString()" is the the path excluding backslashes, because backslash is escape character.
What is the way to read a path from ini file, using QSettings?
Although backslash is a special character in INI files, most Windows applications don't escape backslashes () in file paths [...]
QSettings always treats backslash as a special character and provides no API for reading or writing such entries.
This is what the documentation has to say about it. It is a polite way of saying "if some other code does it, they're not following the WINAPI spec and it's broken and we shouldn't have to deal with it". Pretty much your .ini files are broken.
If you wish to read them, you may need to provide your own backend for QSettings. Such a backend can be easily obtained by copying the one that comes as part of Qt, and modifying it not to perform escaping.
You'd need to investigate whether writing your own QTextCodec for this purpose and passing it to QSettings::setIniCodec would be sufficient. If sufficient, you wouldn't need to provide an entire backend.
To minimize compatibility issues, any # that doesn't appear at the first position in the value or that isn't followed by a Qt type (Point, Rect, Size, etc.) is treated as a normal character.
Although backslash is a special character in INI files, most Windows applications don't escape backslashes () in file paths
enter link description here
I have such files. I just want to open files with non-Latin names correctly.
I have no problems with files that have Latin names only with non-Latin names.
I use QDir for scanning directory and I hold names in QString, so it's held fine inside.
But there is a bottleneck with opening the file.
It gets so that I don't want to use QFile, I can use only C++ streams (more preferred) or C files.
When I want to open file, I do so:
fstream stream(source.toStdString().c_str(),ios_base::in | ios_base::binary);
After that I check whether attempt was successful:
if(!stream.is_open())
{ cout<<"file wasn't opened " <<source.toStdString().c_str())<<"\n";
return false; // cout was redirected to file // just a notice
}
I get in my log file:
file wasn't opened /home/sh/.mozilla/firefox/004_??????? - ????? - ?????.mp3
It doesn't work for any file with non-Latin name and it does work fine for every file with Latin names.
I understand that this problem can be jumped over using QFile.
But I wonder, is it possible to get it done without third-party libraries or are there some another ways for solving it?
Thanks in advance for any tips.
Things are going wrong when you call toStdString() on your QString. It will convert the contents based on QTextCodec::codecForCStrings(), if it has been set, and latin-1 will be used otherwise. Latin-1 will collapse your non-latin characters to '?'s.
Using source.toLocal8Bit().data() or source.toUtf8().data() instead will likely do what you want, but failing that you'll need to deal with QTextCodecs to get the right 8-bit encoding.
I am writing a C++ program which reads lines of text from a .txt file. Unfortunately the text file is generated by a twenty-something year old UNIX program and it contains a lot of bizarre formatting characters.
The first few lines of the file are plain, English text and these are read with no problems. However, whenever a line contains one or more of these strange characters mixed in with the text, that entire line is read as characters and the data is lost.
The really confusing part is that if I manually delete the first couple of lines so that the very first character in the file is one of these unusual characters, then everything in the file is read perfectly. The unusual characters obviously just display as little ascii squiggles -arrows, smiley faces etc, which is fine. It seems as though a decision is being made automatically, without my knowledge or consent, based on the first line read.
Based on some googling, I suspected that the issue might be with the locale, but according to the visual studio debugger, the locale property of the ifstream object is "C" in both scenarios.
The code which reads the data is as follows:
//Function to open file at location specified by inFilePath, load and process data
int OpenFile(const char* inFilePath)
{
string line;
ifstream codeFile;
//open text file
codeFile.open(inFilePath,ios::in);
//read file line by line
while ( codeFile.good() )
{
getline(codeFile,line);
//check non-zero length
if (line != "")
ProcessLine(&line[0]);
}
//close line
codeFile.close();
return 1;
}
If anyone has any suggestions as to what might be going on or how to fix it, they would be very welcome.
From reading about your issues it sounds like you are reading in binary data, which will cause getline() to throw out content or simply skip over the line.
You have a couple of choices:
If you simply need lines from the data file you can first sanitise them by removing all non-printable characters (that is the "official" name for those weird ascii characters). On UNIX a tool such as strings would help you with that process.
You can off course also do this programmatically in your code by simply reading in X amount of data, storing it in a string, and then removing those characters that fall outside of the standard ASCII character range. This will most likely cause you to lose any unicode that may be stored in the file.
You change your program to understand the format and basically write a parser that allows you to parse the document in a more sane way.
If you can, I would suggest trying solution number 1, simply to see if the results are sane and can still be used. You mention that this is medical data, do you per-chance know what file format this is? If you are trying to find out and have access to a unix/linux machine you can use the utility file and maybe it can give you a clue (worst case it will tell you it is simply data).
If possible try getting a "clean" file that you can post the hex dump of so that we can try to provide better help than that what we are currently providing. With clean I mean that there is no personally identifying information in the file.
For number 2, open the file in binary mode. You mentioned using Windows, binary and non-binary files in std::fstream objects are handled differently, whereas on UNIX systems this is not the case (on most systems, I'm sure I'll get a comment regarding the one system that doesn't match this description).
codeFile.open(inFilePath,ios::in);
would become
codeFile.open(inFilePath, ios::in | ios::binary);
Instead of getline() you will want to become intimately familiar with .read() which will allow unformatted operations on the ifstream.
Reading will be like this:
// This code has not been tested!
char input[1024];
codeFile.read(input, 1024);
int actual_read = codeFile.gcount();
// Here you can process input, up to a maximum of actual_read characters.
//ProcessLine() // We didn't necessarily read a line!
ProcessData(input, actual_read);
The other thing as mentioned is that you can change the locale for the current stream and change the separator it considers a new line, maybe this will fix your issue without requiring to use the unformatted operators:
imbue the stream with a new locale that only knows about the newline. This method may or may not let your getline() function without issues.