1

I commonly use boost to implement some features, specially ths boost::filesystem (1.58.0).

Also I use std::experimental to string_view (my compiler didn't include it as standard yet - g++ 5.4.0 20160609).

Because the boost features I use are aprooved I want to be ready to c++17.

Fortunaly I use the following commands in my code:

using namespace boost::filesystem; //the only exeption is to boost::filesystem::remove

using namespace std::experimental;

If I replace the boost line to 'using namespace std::experimental::filesystem;' I will get exactly the same behavior as boost implementation with change nothing more in my code?

And after I get the official gcc compiler with these features already include as standard all I need to do is: a) change the 'std::experimental::filesystem;' to 'std::filesystem' b) delete the line 'using namespace std::experimental;'

and get the same behavior with change nothing more in my code?

Which other boost features are included on c++17 and also can be easily replaced as describe above?

TheArchitect
  • 1,160
  • 4
  • 15
  • 26
  • While some of the new features are based on or inspired by Boost libraries, there might not be a one-to-one translation of the Boost libraries into the standard library. With that said, I doubt there will be anything big or common that have been changed (if anything) so you should be able to use `std::filesystem` just like the Boost filesystem library. – Some programmer dude Jun 15 '17 at 10:33
  • 2
    Boost Filesystem and Boost Threads are the only two that I'm aware of that try to track the standards proposals. This is immediately reflected in by the fact that they have many breaking changes in the public interface (Boost Filesystem v2/v3, and Boost Thread uses a dozen important conditionally compiled feature selection macros) – sehe Jun 15 '17 at 11:06

2 Answers2

4

Boost is not (affiliated with the) ISO standard.

No, you shouldn't blindly expect the semantics to be identical. Even though in 80%-90% of the cases the interface will be compatible, you will get differences.

E.g. boost::optional<T&> is allowed, but not in the standard version. There are other differences.

In general, it's bad practice to use using-directives, especially if you use it to paper of these differences. If you want to keep your dependencies mobile, it's probably best to create your own namespaces, wrapper functions.

In my code-base, e.g. I have used

namespace XXX {

     using nullopt_t = ::boost::none_t;
     static CONSTEXPR nullopt_t nullopt = {};

     template <typename T> using optional = ::boost::optional<T>;
}

We use this interface exclusively in any non-boost specific code.

This should aid in transitioning to the standard library version, except for semantic differences already outlined.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • I understand why is not a good practice to use using directives with external libraries like boost Also I read it is not good to use with std "using namespace std;" and I don't understand why. – TheArchitect Jun 15 '17 at 10:59
  • 3
    It's a choice, obviously. Using-directives in headers are rarely a good thing, because it invites name collisions and can subtly introduce bugs due to e.g. ADL. (The notable exception being inline namespaces and versioning, I guess). See e.g. [Why is using namespace std considered bad practice](https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice) – sehe Jun 15 '17 at 11:03
  • In this case I was motivating _why_ it is not a reliable way to switch implementations: the specifications aren't interchangeable. – sehe Jun 15 '17 at 11:03
1

Boost and the later derived standarizations tend to differ.

In the case of filesystem, there are a few breaking changes. Off the top of my head, a flag was changed to a bitfield of flags.

However 90% of the code works the same.

Instead of using namespace boost::filesystem;, consider using

#ifdef USE_BOOST_FILESYSTEM
  namespace filesystem = boost::filesystem;
#else
  namespace filesystem = std::experitmental::filesystem;
#endif

Now use filesystem:: to prefix your use of the API.

At the handful of spots where the implementation differs, you can use more #ifdef.

The things that are in that namespace now stick out in your code, and you have an #ifdef to handle the corner cases where they aren't compatible.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524