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.
After much research and digging into the Boost libraries documentation, I cannot find answers or high-level advice on the following questions:
Which are the requirements of Boost regarding the C++ language version? C++03? C++11? How can I now which version of Boost requires which version of the C++ language?
Does it depends on the specific library (most of the times, the .hpp file included).
Do I have to check manually (as a last resort) with all the libraries I may need and all the versions of Boost, from the latest and then moving backwards in case I need a less strict dependency?
Which are the dependencies with the C++ Standard Library?
Context:
I am evaluating the use of Boost on an embedded platform (MCU with limited and no virtual memory, no underlying OS).
I have GCC 4.8.1 with C++11 support.
We do not have a complete C++ Standard Library for this platform.
I was hoping to use Boost as a complement and substitute of the C++ Standard Library, hence my research on the topics asked above.
I appreciate the high quality of the Boost project documentation, however, I could not find any reference to the above topics in the official documentation. Maybe I have missed something.
P.S.: A gente introduction to the historically complex topic of C++ language versions, Standard Library and Boost libraries,
http://news.dice.com/2013/03/15/comparing-the-c-standard-and-boost-2/
http://beta.boost.org/development/tests/master/developer/summary.html
This lists some of the platforms boost is tested against.
Every release, boost mentions which platforms it has been tested against.
It is expected to work on more platforms than those listed, but there are no guarantees.
The support and evolution of a boost library in terms of supporting new c++ features is not tightly related to the other libraries. Since boost has been living mainly in a mono standard world (c++03), it was implied that it works in c++03. But as boost people tend to do stuff in a smart way, for the libraries who now support c++11 features, they either use some feature emulation system to keep it working on c++03 or they test for your configuration and if you can't use some advanced stuff then they just disable it.
So basically there is no language standard requirements, it works on all c++03/C++11/C++14 with different features sets.
For other requirements (namely parts of the STL) it directly depends on the libraries you want. The best way is to test. You might find a way to launch their unit test on your plateforme to see how much is working.
You might also want to check Boost Config which is the library that all others use to check for features.
I'm writing for sometime an wrapper library for my own programming language in C++.
Some of the most important intensions of my library is that it must be fast, easy, portable and lightweighted.
Currently it's depending on the Boost libraries. The problem with the boost libraries is that it's relatively large (file sizes). Also, it's depending on static libraries you have to build yourself. Compared to the prebuilt libraries coming with any native compiler (std), it's lacking on 2 out of the 4 intensions:
Easy - Users need to build boost itself
Lightweighted - Boost itself is about 100 MB
I was hoping for some advice, since currently I´m only using boost for purposes std doesn´t provide like threading, file searching and process creation (using unaccepted Boost.Process).
What is the best go for me, stay with boost, writing the libraries myself or maybe you guys know any other good librarie(s) which settle my needs?
Edit: This project is being developed with MinGW on Windows, for portability with other platforms (GCC).
Since the C++11 standard, C++ have threading built into the standard library.
Boost is meant to be the standard non-standard C++ library that every C++ user can use. Is it reasonable to assume it's available for an open source C++ project, or is it a large dependency too far?
Basically your question boils down to “is it reasonable to have [free library xyz] as a dependency for a C++ open source project.”
Now consider the following quote from Stroustrup and the answer is really a no-brainer:
Without a good library, most interesting tasks are hard to do in
C++; but given a good library, almost any task can be made easy
Assuming that this is correct (and in my experience, it is) then writing a reasonably-sized C++ project without dependencies is downright unreasonable.
Developing this argument further, the one C++ dependency (apart from system libraries) that can reasonably be expected on a (developer's) client system is the Boost libraries.
I know that they aren't but it's not an unreasonable presumption for a software to make.
If a software can't even rely on Boost, it can't rely on any library.
Take a look at http://www.boost.org/doc/tools.html. Specifically the bcp utility would come in handy if you would like to embed your boost-dependencies into your project. An excerpt from the web site:
"The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application.bcp can also report on which parts of Boost your code is dependent on, and what licences are used by those dependencies."
Of course this could have some drawbacks - but at least you should be aware of the possibility to do so.
I used to be extremely wary of introducing dependencies to systems, but now I find that dependencies are not a big deal. Modern operating systems come with package managers that can often automatically resolve dependencies or, at least,make it very easy for administrators to install what is needed. For instance, Boost is available under Gentoo-Postage as dev-libs/boost and under FreeBSD ports as devel/boost.
Modern open source software builds a lot on other systems. In a recent study, by tracking the dependencies of the FreeBSD packages, we established that the 12,357 ports packages in our FreeBSD 4.11 system, had in total 21,135 library dependencies; i.e., they required a library, other than the 52 libraries that are part of the base system, in order to compile. The library dependencies comprised 688 different libraries, while the number of different external libraries used by a single project varied between 1 and 38, with a mode value of 2. Furthermore, 5,117 projects used at least one external library and 405 projects used 10 or more.
In the end the answer to your question will come from a cost versus benefit analysis. Is the benefit of re-using a mature, widely used, reviewed, and tested library like Boost and larger than the low and falling cost of a dependency? For any non-trivial use of Boost's facilities the answer is that you should go ahead and use Boost.
It depends. If you're using a header file only defined class template in Boost - then yes go ahead and use it because it doesn't suck in any Boost shared library, as all the code is generated at compile time with no external dependencies. Versioning problems are a pain for any shared c++ library, and Boost is not immune from this, so if you can avoid the problem altogether it's a good thing.
The benefits of using boost when writing C++ code that they significantly outweigh the extra complexity of distributing the open source code.
I work on Programmer's Notepad and the code takes a dependency on boost for test, smart pointers, and python integration. There have been a couple of complaints due to the requirement, but most will just get on with it if they want to work on the code. Taking the boost dependency was a decision I have never regretted.
To make the complexity slightly less for others, I include versioned pre-built libraries for boost python so that all they need to do is provide boost in their include directories.
KDE also depends on Boost.
However it mostly depends on your goals, and even more so on your target audience, rather than the scope of your project. for example TinyJSON (very small project), is almost 100% Boost, but thats fine because the API it provides is Boost-like and targeted at Boost programmers that need JSON bindings. However many other JSON libraries don't use Boost because they target other audiences.
On the other hand I can't use Boost at work, and I know lots of other developers (in their day jobs) are in the same boat. So I guess you could say if your Target is OpenSource, and a group that uses Boost, go ahead. If you target enterprise you might want to think it over and copy-paste just the necessary parts from Boost(and commit to their support) for your project to work.
Edit: The reason we can't use it at work is because our software has
to be portable to about 7 different
platforms and across 4 compilers. So
we can't use boost because it hasn't
been proven to be compatible with
all our targets, so the reason is a
technical one. (We're fine with the
OpenSource and Boost License part,
as we use Boost for other things at
times)
I would say yes. Both Mandriva (Red Hat based) and Ubuntu (Debian based) have packages for the Boost libriaries.
I think the extensive functionality that Boost provides and, as you say, it is the standard non-standard C++ library justifies it as a dependency.
Unfortunately yes, for ubuntu they're readily available but for RHEL 4&5 I've almost always ended up making them from tarballs. They're great libraries, just really big... like using a rail spike when sometimes all you really need is a thumbtack.
It all depends on the way you're going to use Boost. As Diomidis said, if you're going to use some non-trivial facilities from Boost, just go ahead. Using libraries is not a crime.
Of course, there are many people who prefer not to use Boost, because introducing new dependencies has always some cons and extra worries, but in an open source project... in my opinion it's even alright to use them if you just want to learn them or improve your skills on them.
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.