Mohit's answer tells you how to detect failure of std::fstream::open
.
That function would usually use some operating system service to open a file, generally some open system call like open(2) on Linux (which can fail for many reasons).
Your program is buggy because your nof
probably does not contain a valid file path. I would recommend clearing it with memset(nof, 0, sizeof(nof))
before reading it, and using your debugger, e.g. gdb
to find your bug (if you enter a filename of only three characters, or one of fourty letters, your program won't work)
You could ask your operating system for a reason of that failure. On Linux you would use errno(3) (e.g. thru perror(3)).
As far as I know, the C++ standard does not specify how to query the reason of the failure of std::fstream::open
(and probably do not require a relation between fstream
and errno
)
Pedantically, the C++ standard does not require std::fstream
to use operating system files. Of course, in practice, fstream
-s always use them. But in principle you might have a C++14 implementation on something without files or even without an OS (but I cannot name any).
The notion of file is in practice tightly related to operating systems and file systems. You can have OSes without files (in the past, OS/400, PalmOS, GrassHopper and other academic OSes) even if that is highly unusual today.
And the notion of file is specific to an OS: A file on Windows is not the same as a file on Unix or on z/OS.
Languages standard specifications (like C++11 n3337, C11 n1570, Scheme R5RS) are written in English and they are purposely vague on "files" or "file streams" (precisely because different OSes have different notions of them).