Re: [lmi] Replacing boost with std C++11 [Was: Fix value_cast defect shown by the unit test]

[Vadim Zeitlin]

On Mon, 9 Jan 2017 16:18:18 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-09 14:36, Vadim Zeitlin wrote:
GC> > On Mon, 9 Jan 2017 11:20:22 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> It seems straightforward to replace is_base_and_derived with 
is_base_of,
GC> > 
GC> >  Thanks for doing this!
GC> 
GC> I took a look at other lmi uses of boost, to see whether there's anything
GC> else that's simple and mechanical. The first thing that occurred to me was
GC> enable_if...

 FWIW the first thing that occurred to me was static_assert(), which has
special compiler support and is just less ugly than BOOST_STATIC_ASSERT.

GC> enable_if shouldn't be very complicated...but maybe it is. The replies
GC> to this question:
GC> 
GC> http://stackoverflow.com/questions/3111045/where-is-disable-if-in-c0x
GC> 
GC> discuss writing disable_if in terms of std::enable_if, and I can't tell
GC> at a quick glance whether this was actually difficult. But no matter: we
GC> can just replace disable_if with enable_if with the opposite condition,
GC> AFAICT. What really makes me hesitate here is that, as that stackoverflow
GC> article says,
GC> 
GC> | std::enable_if is basically boost::enable_if_c, and that there is
GC> | no such thing as boost::enable_if in C++0x.
GC> 
GC> so using the C++11 feature is a step backward in clarity. However, C++14
GC> adds an enable_if_t that's easier to read, so maybe we should wait.

 If we're waiting for C++17 anyhow, then I'd rather just use "if constexpr"
instead which is much simpler to both write and read.

GC> Similarly, I think we should wait to replace BOOST_STATIC_ASSERT because
GC> C++11's static_assert requires a second argument, which becomes optional
GC> in C++17.

 IMO specifying the second argument is not a big deal and is actually much
more often useful than not, especially if it's used to explain what needs
to be done if the assert fails instead of just repeating the condition
text.

GC> I suppose we might
GC>   s/boost::scoped_ptr/std::unique_ptr/g
GC>   s/boost::shared_ptr/std::shared_ptr/g

 There are some differences between the elements of the latter pair, but I
don't think they can affect lmi code. And the former ones are identical
AFAIK.

GC> and maybe it's also easy to replace these:
GC>   #include <boost/algorithm/minmax_element.hpp>
GC>   #include <boost/cstdint.hpp>

 Yes, definitely.

 Should I do any of this or should I instead finish my other pending C11n
patches? Personally I'd prefer if you could have a look at the pending ones
(https://github.com/vadz/lmi/pull/46, 47 and 48), especially because the
likelihood of conflicts when doing such global changes is pretty high.

 Thanks in advance,
VZ