Boost logo

Boost :

Subject: Re: [boost] "is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows
From: degski (degski_at_[hidden])
Date: 2018-09-20 03:34:58

On Wed, 19 Sep 2018 at 22:03, Adam Hartshorne via Boost <
boost_at_[hidden]> wrote:

> 1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error
> : no template named 'is_assignable'; did you mean 'std::is_assignable'?
> 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded

You probably need to give information as to which library triggers this
error, as has_trivial_move_assign.hpp is pulled in by almost all libraries
and this "detection error" is upstream.

There is (generally, but some libs have been fixed for this) a mismatch
(deficiency) between the way clang-cl identifies it self (__clang__ **and**
_MSCVER) and the way Boost libs try to identify the compiler used. So
libraries that simply check for _MSCVER and then assume it's MSVC will show
this problem, also checking in the wrong order can generate this problem.

I've signaled this many times before, but this has always fallen on deaf
ears. Also clang-cl is not in the test matrix, as Boost cannot be built in
its entirety with clang-cl and only few people seem to think that there is
any merit in trying to get that to work (even though Clang/LLVM provide for
better tooling in every respect (also better binaries) and also allows for
beginners to actually learn proper C++ as the warning messages (and hints)
are actually discernible even for a beginner, contrary to the stuff that
comes out of MSVC).

These discussions usually end in a rant over the non-conforming MSVC-PP
(which by now is conforming, but the one from VS-7.1 will keep on being
broken and the focus seems to be on supporting that).


*“If something cannot go on forever, it will stop" - Herbert Stein*

Boost list run by bdawes at, gregod at, cpdaniel at, john at