Is there a way to read file names from a folder using purely C (or C++)? That means without including windows.h (no FindFirstFile(), etc...).
It doesn't look like fstream has this functionality. I know that file names are operating system dependent, but I was hoping there is some library that will allow it in Windows.
boost filesystem is a nice solution. Of course under the hood, it will still be using the windows API calls (when you build on windows), but this is abstracted away from you.
C++ typically does not supply you with such functionality. A cross-platform solution is to use boost::filesystem.
Try the POSIX functions opendir() and readdir() for iterating through directories. See this link for the manual page with some great example code. These functions should be available on most platforms, both Windows and UNIX.
If you wish to use opendir() and readdir() on windows, you can download MinGW, a windows port of the famous GNU compiler collection. It includes windows ports of the UNIX header files, including dirent.h, which will allow you to use the specified functions. Keep in mind these will call native API's either way.
-John
Related
I'm using visual studio on windows and I have this header file called windows.h which of course gives me access to the win32 API.
but when I try to use other platforms API like the linux API for example. I don't find any header file with that name, which mean that I can't use any other OS API than windows,
now the problem here is: what if I wan't to make a cross platform program for example ? when I don't have the appropriate access to its API, I tried to do some researches for a sometime but couldn't get any answer to my questions, which is really troubling my mind right now, so to be more specific these are my questions:
1- why I can only use the windows API out of all the other operating systems ?
is it because I'm coding on windows, so if I was coding "somewhere else" it would be different ?
or is it something related to the compiler itself ?
2- what if I want to use another API do I have to use an external library ? and if that's the case how is the Standard Library in c++ cross platform, I mean if it is cross platform then there should exist other platform specific headers provided by the library right ?
I'm using visual studio on windows and I have this header file called windows.h which of course gives me access to the win32 API.
Strictly speaking windows.h is sort of a meta-header. Some important macros, tokens and symbols are defined in windows.h, but it also pulls in a lot of other headers. If you look at the reference manual of each of the Win32 API functions it will tell you there, which header that function is declared in. Let's have a look at CreateFileA for example: At the bottom of the reference manual you'll find:
Requirements
Minimum supported client Windows XP [desktop apps only]
Minimum supported server Windows Server 2003 [desktop apps onliy]
Target Platform Windows
Header fileapi.h (include Windows.h)
Library Kernel32.lib
DLL Kernel32.dll
So this tells us, that CreateFileA actually is declared in fileapi.h and is exported from the kernel32.dll system library.
but when I try to use other platforms API like the linux API for
example.
That is, because there is no linux.h API header (if you search a Linux development system for files named linux.h you'll find plenty, but those are not used for the system level API).
The reason for that is, that Linux doesn't have its very own, proprietary API, but folloes the POSIX industry standard for operating system APIs, and the Single Unix Specification maintained by the Open Group.
There are of course Linux specific APIs, but you can safely ignore them for "usual" application development; you need those if you're doing low level stuff, like writing a C runtime library, or custom memory allocators.
Of most interest for you, as a developer are the manpages in section 2 (calls into the operating system kernel = syscalls) and section 3 (library functions). https://linux.die.net/man/
The POSIX equivalent to CreateFileA would be open which you can find in section 2: https://linux.die.net/man/2/open (or the creat syscall, that exists for legacy reasons, but nobody uses that (or should use it)).
If you look at the manpage of open it tells you
open(2) - Linux man page
Name
open, creat - open and possibly create a file or device
Synopsis
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);
That tells you, that in order to use open you need to include sys/types.h, sys/stat.h and fcntl.h. Unlike Windows there's no all overencompassing header that pulls in everything. The reason for this is, that for backwards and cross compatibility reasons the things that are exposed by a header can be configured by setting certain macros to specific values before including the header. Those are explained in feature_test_macros(7), and for functions where they apply these are also mentioned in the respective manual page.
I don't find any header file with that name, which mean that
I can't use any other OS API than windows,
Just because you can't find it, doesn't mean it doesn't exist.
now the problem here is: what if I wan't to make a cross platform program for example?
Then you write all the platform specific things into a separate .c file, that encapsulates the OS stuff.
when I don't have the appropriate access to its API
Well, you do.
1- why I can only use the windows API out of all the other operating systems?
Because you can't. Windows.h is available only on Windows systems.
2- what if I want to use another API do I have to use an external library?
Then you just use it.
Keep in mind that in Linux the graphical environment is not part of the main operating system. It's in fact a regular program that is automatically launched on system start. Hence you won't find documentation for that in the aforementioned manpages.
The default graphics enviroment for Linux is Xorg (an open implementation of the X11 display system). There's also Wayland, but after over 10 years in development it's still poorly supported and leaves a lot to be desired.
If you want to program X11 on the same level as Win32, you'll have to deal with the Xlib or Xcb. However direct X11 programming is quite tedious. You probably want to use some nice application framework like Qt or GTK. Qt by itself is a cross platform framework, so if you limit yourself to use only, and only Qt functions, your program will be fully cross platform without extra effort. If you want to do 3D graphics on the GPU, use the cross platform APIs OpenGL or Vulkan.
but when I try to use other platforms API like the linux API for example. I don't find any header file with that name
There is no header called <linux> for the system API. The POSIX operating system specification (which Linux conforms to) lists several headers which contain the functionality that you might find from windows.h on that system. POSIX spec overlaps with the C standard library, and the C standard library implementation also provides the POSIX specific headers. See the Linux manual or POSIX spec for full list of headers.
what if I want to use another [system] API
You will need at least the header files of that API in order to compile programs that call them. Furthermore, you'll need the library archives in order to link your programs. And you'll need to tell the compiler which system you are targeting. By default, all compilers assume that you target the system that is running the compiler. You'll need to consult the documentation of your compiler about whether cross compilation is possible, and how to do it.
Or a simpler approach: Compile on the system where the API is provided. The headers may need to be installed separately.
... how is the Standard Library in c++ cross platform
Each system has their own standard library. Some of the implementations of standard library are cross platform, but not all. For example, the libstdc++ - which is the standard library that is part of the GNU project, and is the default standard library in Linux - is available on many platforms including Windows. By contrast, the Msvc standard library is only available on Windows.
The Wikipedia about windows.h library says:
windows.h is a Windows-specific header file for the C and C++
programming languages which contains declarations for all of the
functions in the Windows API, all the common macros used by Windows
programmers, and all the data types used by the various functions and
subsystems.
Linux doesn’t provide a default API for window management as does Windows so if you are programming a graphical application then you need to choose a windowing library as well.
The answer to part one is yes. You can only use the Windows API because you are programming on Windows. However you can run Linux on Windows. A Microsoft product called the Windows Subsystem for Linux allows you to do that. But even if you do that you won't find a header called linux.h, it's more complicated than that. There is also a product (called WINE I believe) that lets you use the Windows API on Linux, although I believe it has a few issues.
The standard library interface is cross platform, but it's implementation certainly isn't. It does this by abstracting away OS specific features. If you look at how the library is implemented on different platforms you will certainly see lots of differences.
My goal is simple: I'd like a to clear a directory (delete all of the sub-directories and files it contains, but not delete the directory itself) given a path, in a cross-platform way.
Most of the solutions I've found online either involve using dirent.h which, from my understanding, is non-standard and may not work on non-POSIX systems (notably Windows) or using Boost.Filesystem. However, building Boost and including it in my project is a lot to ask for if all I'd like to do is clear a directory.
Is there a way to achieve my goal in standard C++? Or, has the standard not advanced to this point yet?
A filesystems library was "added" to C++ in the "Filesystems TS", so you may be able to find an experimental implementation in your compiler's standard library implementation.
However, it's not yet part of any formal standard. My understanding is that it'll be part of C++17.
Until then, Boost it is — or your own hand-crafted code on systems that are neither Windows nor POSIX-compliant.
idevs.h, netinet/in_systm.h, netinet/ip.h, netinet/tcp.h openssl/ssl.h sys/socket.h
These header files can work in Linux but in visual studio 2008 compile error says unable to open header file. These are socket program related headers. (I am unable to get any proper result from web search)
Problem:
Please let me know any dll I have include for these headers or any other equivalent headers are available ?
Thanks in advance.
In windows environment you need to include the windows specific headers like winsock.h and others (http://msdn.microsoft.com/en-us/library/windows/desktop/ms738545(v=vs.85).aspx). You need to switch between headers using the #ifdef statements when doing builds for different platforms.
Nobody ever promised that windows implementation of the sockets concept is 100% identical to the one of Unix. These implementations have a lot in common, but differences are also present.
Sockets are not part of the C++ standard and are implemented in different ways in Linux and Windows. That means, that the native socket libraries are different in both OSes, and Windows has other headers for its socket API than Linux. So you will not only have to include other headers but might also need to use other functions.
Depending on what you want to achieve, you might want to use a library that wraps the OS specific parts and provides a portable interface. There are several more or less portable networking libraries, one of the best known might be Boost.Asio
in C++, what would be the best way to list all files of a directory on Windows?
On Linux or on Windows using gcc (e.g. MingW) this is easy possible with dirent.h, but what's the best way to do it on Windows when dirent.h is not available (e.g. Visual Studio)?
Should I force people do add a freely available implementation of dirent.h to their Visual Studio? Or should I write an alternative code for reading the files? If this, what would be the best code to do so?
Thanks.
dirent.h is a POSIX header. On Windows you use the Find*File*() functions in the Win32 API.
Something like Boost Filesystem would work across all of those situations.
To add to the answer above, Windows API is accessed via the windows.h header file included.
I can't seem to find the _findfirst / findfirst, _findnext / findnext API on gcc for Linux, and would actually rather use the Standard Template Library (STL) for that if it is included there.
Does anyone know what API there is available for listing files in a directory under Linux for C++ (gcc)?
It's not a C++-style API, but the API you aren't finding (the Linux/Unix correspondent of DOS/Windows-style findfirst/findnext) is opendir/readdir/closedir.
The main advantage of using opendir/readdir/closedir is that you do not need any extra library (it's part of the C library, which you are already using). In fact, the Boost filesystem library uses opendir/readdir/closedir to get the list of files in a directory.
References:
http://www.opengroup.org/onlinepubs/009695399/functions/opendir.html
http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html
http://www.opengroup.org/onlinepubs/009695399/functions/closedir.html
Check out the Boost.Filesystem library.
In particular, the basic_directory_iterator.
The STL does not, yet, have functions for listing files in a directory. But it does have functions for opening files you are already aware of.
Aside from Boost.Filesystem, there is also STLSoft
Since C++17 the standard library contains std::filesystem which has its source in Boost.Filesystem. Nowadays std::filesystem::directory_iterator is the obvious choice since it is platform-independent, offers better abstraction than _findfirst/findnext/opendir/readdir/closedir and doesn't introduce any dependencies. If you can't use a C++17-compliant compiler use Boost for now and switch over later.