boostorg/config

Boost.org config module

config's Issues

BOOST_OVERRIDE

The question about BOOST_OVERRIDE was on mail list a long time ago https://lists.boost.org/Archives/boost/2013/07/205180.php; there also was a PR adding it #82. The macro is still in demand. Can we do about it something? If you wish I could extract BOOST_OVERRIDE (and possibly BOOST_FINAL) from #82 as a separate small PR.

Fix boost (>= 1.66) on gcc 4.9.3

When trying to use boost 1.66 on gcc 4.9.3 (not sure about 4.9.4; we use gcc 4.9.3 as it is the last "known good" version for gccxml) we encountered a strange bug related to gcc's handling of __has_include:
The macro is defined but not implemented correctly.
Our workaround was to conditionally undefine the macro when encountering gcc 4.9.x.

diff -rpu boost_1_66_0_old/boost/config/stdlib/libstdcpp3.hpp boost_1_66_0/boost/config/stdlib/libstdcpp3.hpp
--- boost_1_66_0_old/boost/config/stdlib/libstdcpp3.hpp	2017-12-14 00:56:42.000000000 +0100
+++ boost_1_66_0/boost/config/stdlib/libstdcpp3.hpp	2018-04-25 16:42:42.627694409 +0200
@@ -301,6 +301,11 @@ extern "C" char *gets (char *__s);
 #  define BOOST_NO_CXX17_STD_APPLY
 #endif
 
+#if defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 9) && defined(__has_include)
+// gcc 4.9.x defines but does not implement it
+#undef __has_include
+#endif
+
 #if defined(__has_include)
 #if !__has_include(<shared_mutex>)
 #  define BOOST_NO_CXX14_HDR_SHARED_MUTEX

clang++-libc++ on Trusty doesn't seem to support thread_local

I added a few more configurations to Travis here: 0ac815e

and the clang++-libc++ one (which uses the provided libc++-dev package) fails when thread_local is used with

/home/travis/build/boostorg/boost-root/libs/config/test/boost_no_cxx11_thread_local.ipp:20: undefined reference to `__cxa_thread_atexit'

https://travis-ci.org/boostorg/config/jobs/329979139#L2474

I'm not quite sure what we ought to do about that; either define BOOST_NO_CXX11_THREAD_LOCAL for libc++ on Linux, or somehow figure out a way to make that config work. I think I tend towards the former.

(Having a working libc++ Linux Travis config is nice as it doesn't need to wait for the permanently clogged Mac jobs.)

BOOST_HAS_INTPTR_T is undocumented.

Moved from Trac.

Add BOOST_ATTRIBUTE_NODISCARD

Similar to BOOST_ATTRIBUTE_UNUSED, it would be nice to have a macro which adds the nodiscard attribute when that is available.

#if __cplusplus >= 201703L
#define BOOST_ATTRIBUTE_NODISCARD [[nodiscard]]
#else
#define BOOST_ATTRIBUTE_NODISCARD
#endif

QNX 7.0 LLVM cxx bugfix

Hi there,
I get serval compiler errors when compiling Boost source 1.70.0 (currently available version) as shared/static libraries with QNX SDP 7.0 (GCC 5.4.0).

This has been discussed here too: boostorg/asio#248 (comment)

output

See attached output file:
boost_qnx_70_cxx_error.txt

the error

The error is a combination of code and compiler configuration (through compiler header files).
Boost uses a feature that gets disabled when using the LLVM C++ library what results in the compiler errors.
Actually when using a QCC target that uses the GNU C++ library gpp everything works fine only with the LLVM C++ library cxx this error occurs.

error origin

The problem is located in the header file target/qnx7/usr/include/c++/v1/__config in the #ifdef block at line 409 (or with current QNX SDP 7.0 update at line 412):

#if defined(GNUC)

In this block the macro _LIBCPP_HAS_NO_TEMPLATE_ALIASES gets defined at line 432 (or with current QNX SDP 7.0 update at line 435):

#define _LIBCPP_HAS_NO_TEMPLATE_ALIASES

This is actually wrong as the GCC compiler supports the template alias feature since version 4.7.

workaround 1: works with every user code

One can circumvent the problem by undefining the macro after the __config file gets included.
But then one has to ensure the header inclusion order in the code what could be tricky sometimes.

It is possible to circumvent the problem without changing the compiler headers, code or introducing additional macro arguments.

1. create a file named __config
2. put that file in a path which is accessible from the code project (readable)
3. write the following code into that file:

// This is a workaround for a problem with QNX 7 / qcc 5.4 and LLVM C++ library.
// E.g. boost cannot be compiled without this as with the LLVM C++ library qcc
// disables several compiler features which is a misconfiguration of the
// compiler settings.

#ifndef __QCC-5-4_CXX___CONFIG_66771214-7934-4DDC-94A3-B0511E80AE69__
#define __QCC-5-4_CXX___CONFIG_66771214-7934-4DDC-94A3-B0511E80AE69__

#include_next <__config>
#if defined(__QNXNTO__) && \
    (defined(__cpp_alias_templates) && (__cpp_alias_templates >= 200704L)) || \
    (defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 7))))
#    undef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
#endif

#endif // __QCC-5-4_CXX___CONFIG_66771214-7934-4DDC-94A3-B0511E80AE69__

4. put the path to this file into the header search paths
   e.g. q++ ... -isystem c:/path/to_the_file
5. compile the code normally without any changes

What happens here is that a feature of GCC/QCC is used include_next (see docs here) to "override" the inclusion of the header file globally (in the context of the compilation) and instead include the custom one.

To make things easier see the following attachment:
__config.zip

workaround 2: works with every user code

This workaround is not recommended as it will only work with the specifically modified header files of the compiler installation.
Manipulate the compiler header file target/qnx7/usr/include/c++/v1/__config and comment the problematic line #define _LIBCPP_HAS_NO_TEMPLATE_ALIASES to // #define _LIBCPP_HAS_NO_TEMPLATE_ALIASES.

BOOST_NO_CXX17_HDR_STRING_VIEW defined while string_view available

Using clang-8 on Ubuntu 18.04, I am having BOOST_NO_CXX17_HDR_STRING_VIEW defined in Boost.Test while it looks to me that this is properly supported by the toolchain.

I am compiling the program with this:

cd libs/test/test
../../../b2 address-model=64 cxxstd=17 toolset=clang-8.0 basic_cstring-test

In the program, I added this:

#include <string_view>

#if defined(BOOST_NO_CXX17_HDR_STRING_VIEW)
#error no hdr defined
#endif

and the error fires on the #error pragma.

The location where is defined is in boost/config/stdlib/libstdcpp3.hpp, in the section (line 300):

#if (BOOST_LIBSTDCXX_VERSION < 70100) || (__cplusplus <= 201402L)

/// added by me for debugging
#ifdef __clang__
// clang is defined
#endif

#if (BOOST_LIBSTDCXX_VERSION < 70100)
// this is defined
#endif

#error found where defined
/// added by me for debugging - end

#  define BOOST_NO_CXX17_STD_INVOKE
#  define BOOST_NO_CXX17_STD_APPLY
#  define BOOST_NO_CXX17_HDR_OPTIONAL
#  define BOOST_NO_CXX17_HDR_STRING_VIEW
#  define BOOST_NO_CXX17_HDR_VARIANT
#endif

Is this intentional? What would be the correct way to compile with string_view support?
Thanks,
Raffi

Add BOOST_NO_CXX11_HDR_EXCEPTION to Boost.Config

BOOST_NO_CXX11_HDR_EXCEPTION => The standard library does not provide a C++11 compatible version of .

In particular, for Issue boostorg/exception#10 I would need to detect compiler support for C++11 std::exception_ptr and std::current_exception().

I'll try to come up with a PR, but I can only test on two compilers (VS2015 and VS2017) and both provide a C++11 compatible .

Is there any way I can test a PR against remote testers using other compilers?

Test failures on Cygwin g++

cstdint_test.cpp:

test\cstdint_test.cpp(119): test 'sizeof(T1) == sizeof(T2)' failed in function '
void integral_constant_type_check(T1, T2) [with T1 = signed char; T2 = int]'
test\cstdint_test.cpp(119): test 'sizeof(T1) == sizeof(T2)' failed in function '
void integral_constant_type_check(T1, T2) [with T1 = unsigned char; T2 = int]'
test\cstdint_test.cpp(120): test 't1 == t2' failed in function 'void integral_co
nstant_type_check(T1, T2) [with T1 = unsigned char; T2 = int]'
test\cstdint_test.cpp(136): test 't2 > 0' failed in function 'void integral_cons
tant_type_check(T1, T2) [with T1 = unsigned char; T2 = int]'
test\cstdint_test.cpp(119): test 'sizeof(T1) == sizeof(T2)' failed in function '
void integral_constant_type_check(T1, T2) [with T1 = short int; T2 = int]'
test\cstdint_test.cpp(119): test 'sizeof(T1) == sizeof(T2)' failed in function '
void integral_constant_type_check(T1, T2) [with T1 = short unsigned int; T2 = in
t]'
test\cstdint_test.cpp(120): test 't1 == t2' failed in function 'void integral_co
nstant_type_check(T1, T2) [with T1 = short unsigned int; T2 = int]'
test\cstdint_test.cpp(136): test 't2 > 0' failed in function 'void integral_cons
tant_type_check(T1, T2) [with T1 = short unsigned int; T2 = int]'
OK
8 errors detected.

and config_test.cpp:

In file included from test\boost_no_cxx14_hdr_shared_mutex.ipp:13:0,
                 from test\config_test.cpp:306:
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex: In member function '
void std::__shared_mutex_pthread::lock()':
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex:105:51: error: 'pthre
ad_rwlock_wrlock' was not declared in this scope
       int __ret = pthread_rwlock_wrlock(&_M_rwlock);
                                                   ^
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex: In member function '
bool std::__shared_mutex_pthread::try_lock()':
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex:115:54: error: 'pthre
ad_rwlock_trywrlock' was not declared in this scope
       int __ret = pthread_rwlock_trywrlock(&_M_rwlock);
                                                      ^
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex: In member function '
void std::__shared_mutex_pthread::unlock()':
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex:125:77: error: 'pthre
ad_rwlock_unlock' was not declared in this scope
       int __ret __attribute((__unused__)) = pthread_rwlock_unlock(&_M_rwlock);
                                                                             ^
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex: In member function '
void std::__shared_mutex_pthread::lock_shared()':
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex:141:42: error: 'pthre
ad_rwlock_rdlock' was not declared in this scope
  __ret = pthread_rwlock_rdlock(&_M_rwlock);
                                          ^
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex: In member function '
bool std::__shared_mutex_pthread::try_lock_shared()':
/usr/lib/gcc/i686-pc-cygwin/6.4.0/include/c++/shared_mutex:152:54: error: 'pthre
ad_rwlock_tryrdlock' was not declared in this scope
       int __ret = pthread_rwlock_tryrdlock(&_M_rwlock);
                                                      ^

Clang-CUDA is not being distinguished from NVCC

I've recently (as of Boost 1.71) run into two problems related to compilation of CUDA code using Clang:

1. Boost.Optional is broken since 1.69. For example, compilation of the following simple program will fail with error: use of overloaded operator '=' is ambiguous (with operand types 'boost::optional<int>' and 'int'):

       #include <boost/optional.hpp>
   
       int main() {
           boost::optional<int> maybe_int;
           maybe_int = 42; 
           return 0;
       }

   I believe the change that introduced this regression is the fix for #237. What happens is that Boost assumes NVCC is being used to compile CUDA, and tries to determine its version. Since that is not set however, it defaults to an older version that does not support variadic templates (BOOST_NO_CXX11_VARIADIC_TEMPLATES). Additionally the compiler is also detected to be __clang__, which ultimately causes Boost.Optional to define two versions of an assignment operator, causing this ambiguity.

2. Boost.PP's variadic macros are also broken since 1.69, due to a separate change but conceptually in the same vein. I've opened a dedicated issue there.

To remedy this, I suggest to detect NVCC based on __NVCC__ instead of __CUDA__ or __CUDACC__. See here for more information on how to distinguish Clang from NVCC when compiling CUDA. Care has to be taken however to ensure that the correct branches are being taken when Clang is being used as NVCC's host compiler.

MSVC 1916 does not have a good constexpr 14 support

Looks like BOOST_CXX14_CONSTEXPR should not expand into constexpr for _MSC_VER == 1916, because the support does not seem complete. Here are some errors from the Boost.TypeIndex tests:

[00:03:17] compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\type_index_constexpr_test.test\msvc-14.1\debug\cxxstd-14-iso\threading-multi\type_index_constexpr_test.obj
[00:03:17] type_index_constexpr_test.cpp
[00:03:17] type_index_constexpr_test.cpp(97): error C2131: expression did not evaluate to a constant
[00:03:17] C:\boost-local\boost/type_index/ctti_type_index.hpp(185): note: failure was caused by attempting to access a member on an object of dynamic type 'boost::typeindex::type_index_facade<boost::typeindex::ctti_type_index,boost::typeindex::detail::ctti_data>' in which the member is not defined
[00:03:17] C:\boost-local\boost/type_index/ctti_type_index.hpp(185): note: see usage of 'boost::typeindex::ctti_type_index::data_'
[00:03:17] type_index_constexpr_test.cpp(100): error C2131: expression did not evaluate to a constant

Full log is available at https://ci.appveyor.com/project/apolukhin/type-index/builds/21035855/job/9hcff3l2j4r9o70v

Misc: TypeIndex workaround that helped to fix the test boostorg/type_index@c585d74 .

Wrong gcc version for BOOST_NO_CXX11_AUTO_DECLARATIONS

BOOST_NO_CXX11_AUTO_DECLARATIONS is currently under // C++0x features in 4.4.n and later
However gcc 4.4.7 (as in RedHat 6 for example) does not support this feature, error messages:
thirdparty/boost/boost/test/tree/test_case_template.hpp:172: error: expected nested-name-specifier before 'tuple_t'
thirdparty/boost/boost/test/tree/test_case_template.hpp:172: error: 'tuple_t' has not been declared
thirdparty/boost/boost/test/tree/test_case_template.hpp:172: error: expected ';' before '=' token
thirdparty/boost/boost/test/tree/test_case_template.hpp:172: error: expected primary-expression before '=' token
thirdparty/boost/boost/test/tree/test_case_template.hpp:172: error: expected primary-expression before ';' token
thirdparty/boost/boost/test/tree/test_case_template.hpp:173: error: expected nested-name-specifier before 'this_type'
(and so on)

Or if the macro was meant to refer to the "auto" keyword then an extra one is needed for "using" for type declarations, though not sure that is worth the pain.

Should boost force symbol visibility if built as a static lib?

I'm consuming boost::asio as a static library in a project that is delivered as a shared library. To avoid conflicts in clients, I try to hide all symbols originating from my dependencies by linking with -Wl,--exclude-libs,ALL.

To my surprise, this does not work for boost::asio. A little research showed that at some point it was deemed a good idea to force default visibility on exception typeinfo and support classes for printing the exceptions from boost, see eg. https://svn.boost.org/trac10/ticket/4594 which proposed a #pragma visibility push default, only conditional on the compiler. So regardless of whether boost is built as a static or a dynamic library, the symbols get marked with default visibility on GCC.

And now I wonder if this is really the correct policy, or if boost (and any library) should rather refrain from explicitly setting visibility attributes when building a static library. Doesn't that make more sense?

Right now I have a nasty symbol leak that causes conflicts in my clients using a different version of asio. Updated: the problem has been reported before, along with a possible solution, see https://svn.boost.org/trac10/ticket/12722.

N.B.: moved here from boostorg/asio#145

clang++-libc++ with clang6 and libcxxabi does support thread_local

I've been upgrading some company internal projects to use a clang6 toolchain, and discovered that the fix in #208 is causing boost::fiber to not build since it thinks thread_local isn't available.

I can successfully build and run the test case in boost_no_cxx11_thread_local.ipp when i import it in to the project (we're using cmake). This is with the compiler flags:

cxx:
-stdlib=libc++ -fPIE -pthread -std=c++1z

link:
-stdlib=libc++ -static-libstdc++ -Wl,-Bstatic -lc++abi -Wl,-Bdynamic -pthread 

Checking the symbols against the debian 8 prebuilts from http://releases.llvm.org/

clang 6:
> nm -C libc++abi.so | grep __cxa_thread
0000000000027350 T __cxa_thread_atexit
                 U __cxa_thread_atexit_impl@@GLIBC_2.18

clang 5:
> nm -C libc++abi.so | grep __cxa_thread
000000000003c020 T __cxa_thread_atexit
                 U __cxa_thread_atexit_impl@@GLIBC_2.18

clang 3.4 on ubuntu trusty, via apt-get install clang libc++-dev libc++abi-dev:
> nm -CD ./usr/lib/x86_64-linux-gnu/libc++abi.so | grep __cxa_thread
<no results>

So it seems that clang3's libc++abi didn't have support for __cxa_thread_atexit, but newer versions do by deferring to glibc's implementation.

The feature check should probably be changed to detect the clang version?

This may not work 100% of the time though, since it depends on what standard library is being linked in and if libcxxabi is being linked in. Based on the commit llvm-mirror/libcxxabi@3f7b370 more recent versions of clang will attempt to provide a fallback in libcxxabi if glibc does not have an implementation, so perhaps require a very recent version of clang?

CUDA8.X + Visual C++ 2015 does not require "BOOST_NO_CXX11_NOEXCEPT"

I worked around on building NVCaffe 0.15 with VC++2015 & VCPKG boost(1.67) and met this issue.

C:/Tools/vcpkg-export-20180618-223846/installed/x64-windows/include\boost/system/error_code.hpp(240): error C2694: 'const char *boost::system::error_category::std_category::name(void) const': overriding virtual function has less restrictive exception specification than base class virtual member function 'const char *std::error_category::name(void) noexcept const' 

To handle this error, I found out "BOOST_NO_CXX11_NOEXCEPT" is not necessary when you use VC++2015(or other MSVC compiler?) as the back end of NVCC.

What I did:
https://github.com/Chachay/caffe/blob/93bf1e9d8f1c0b31b21621cf48a5d42e4530b515/cmake/Cuda.cmake#L284

What I would like to suggest to do right:

config/include/boost/config/compiler/nvcc.hpp

Line 53 in 9fd87d6

#if (BOOST_CUDA_VERSION >= 8000000) && (BOOST_CUDA_VERSION < 8010000)

to

#if (BOOST_CUDA_VERSION >= 8000000) && (BOOST_CUDA_VERSION < 8010000) && !defined(_MSC_VER)

Lack of support for C++17 [[fallthrough]] attribute with Intel 18 compiler

Intel compiler 18 supports [[fallthrough]] attribute but Config doesn't define BOOST_FALTHROUGH for this compiler. When compiled with Linux Intel compiler 18.0 update 1 in gcc7 environment it seems that GCC BOOST_FALLTHROUGH definition is used which results in:

warning #1292: unknown attribute "fallthrough"

This is only my guess based on the fact that with GCC the definition is:

#  define BOOST_FALLTHROUGH __attribute__((fallthrough))

See e.g. Boost.Geometry test results.

Is 1_69_0 auto_link.hpp missing BOOST_LIB_ARCH_AND_MODEL_OPT for the BOOST_AUTO_LINK_TAGGED option?

After building Boost version 1.69.0 using --layout=tagged my Windows dll names now include the architecture (e.g. boost_atomic-mt-gd-x64.dll), however the auto-link feature does not include this when forming the lib name to link against? LIB_DIAGNOSTIC message is 'Linking to boost_atomic-mt-gd.lib' and hence the linker fails to link.

Should auto_link.hpp be changed from:
Line 407:

#ifdef BOOST_AUTO_LINK_TAGGED
#  pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT ".lib")
#  ifdef BOOST_LIB_DIAGNOSTIC
#     pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT ".lib")
#  endif

To:

#ifdef BOOST_AUTO_LINK_TAGGED
#  pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT ".lib")
#  ifdef BOOST_LIB_DIAGNOSTIC
#     pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT ".lib")
#  endif

Boost is not correctly configured on modern Mac with Intel C++ Compiler

Boost does not work properly on modern macOS, for example 10.11, with Intel C++ Compiler.

When compiling with default language/standard/compatibility flags, select_compiler_config.hpp picks up intel.hpp which does not define BOOST_NO_RTTI and BOOST_NO_RTTI due to INTEL_RTTI. This is wrong, since Intel C++ 2016 builds upon LLVM/Clang which does not have RTTI. As a result, if your application uses RTTI-dependent operators (like typeid()), it breaks.

When you compile with the following flags:

-no-use-intel-optimized-headers -no-intel-extensions -no-icc -no-gcc

...then Boost picks up clang.hpp. But the Clang version handling in this header file is broken since Apple has different versioning scheme for Clang.

However, if you use the flag -clangxx-name= with a custom Clang version, then the Clang versioning scheme is back to normal.

When building with Intel C++ on macOS, both Clang and Intel compiler specific settings need to be considered.

Moved from Trac.

Bad feature detection for nvcc and clang as a host compiler.

Boost feature detection is wrong if the source is compiled with nvcc and clang as host compiler.

For example, move semantics can't be used with c++11 enabled.

#include <utility>                                                                                                                                                                                            

#include <boost/variant.hpp>                                                                                                                                                                                  

class TestClass                                                                                                                                                                                               
{                                                                                                                                                                                                             
public:                                                                                                                                                                                                       
    TestClass() = default;                                                                                                                                                                                    
    TestClass(const TestClass &) = delete;                                                                                                                                                                    
    TestClass(TestClass &&) = default;                                                                                                                                                                        
};                                                                                                                                                                                                            


int main() {                                                                                                                                                                                                  
    TestClass c1;                                                                                                                                                                                             
    boost::variant<TestClass> v{std::move(c1)};                                                                                                                                                               
    return 0;                                                                                                                                                                                                 
}        

When compiled with (ubuntu 16.04, gcc 5.4, CUDA 9.1):

nvcc temp.cu -o temp -ccbin=/usr/bin/gcc -std=c++11

everything works well, but

nvcc temp.cu -o temp -ccbin=/usr/bin/clang-4.0 -std=c++11

fails with the following:

/usr/include/boost/variant/detail/initializer.hpp(110): error: function "TestClass::TestClass(const TestClass &)"
te`
mp.cu(10): here cannot be referenced -- it is a deleted function
          detected during:
            instantiation of "int boost::detail::variant::make_initializer_node::apply<BaseIndexPair, Iterator>::initializer_node::initialize(void *, boost::detail::variant::make_initializer_node::apply<BaseIndexPair, Iterator>::initializer_node::param_T) [with BaseIndexPair=boost::mpl::pair<boost::detail::variant::initializer_root, mpl_::int_<0>>, Iterator=boost::mpl::l_iter<boost::mpl::list1<TestClass>>]" 
/usr/include/boost/variant/variant.hpp(1538): here
            instantiation of "void boost::variant<T0_, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19>::convert_construct(T &, int, mpl_::false_) [with T0_=TestClass, T1=boost::detail::variant::void_, T2=boost::detail::variant::void_, T3=boost::detail::variant::void_, T4=boost::detail::variant::void_, T5=boost::detail::variant::void_, T6=boost::detail::variant::void_, T7=boost::detail::variant::void_, T8=boost::detail::variant::void_, T9=boost::detail::variant::void_, T10=boost::detail::variant::void_, T11=boost::detail::variant::void_, T12=boost::detail::variant::void_, T13=boost::detail::variant::void_, T14=boost::detail::variant::void_, T15=boost::detail::variant::void_, T16=boost::detail::variant::void_, T17=boost::detail::variant::void_, T18=boost::detail::variant::void_, T19=boost::detail::variant::void_, T=const TestClass]" 
/usr/include/boost/variant/variant.hpp(1683): here
            instantiation of "boost::variant<T0_, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19>::variant(const T &) [with T0_=TestClass, T1=boost::detail::variant::void_, T2=boost::detail::variant::void_, T3=boost::detail::variant::void_, T4=boost::detail::variant::void_, T5=boost::detail::variant::void_, T6=boost::detail::variant::void_, T7=boost::detail::variant::void_, T8=boost::detail::variant::void_, T9=boost::detail::variant::void_, T10=boost::detail::variant::void_, T11=boost::detail::variant::void_, T12=boost::detail::variant::void_, T13=boost::detail::variant::void_, T14=boost::detail::variant::void_, T15=boost::detail::variant::void_, T16=boost::detail::variant::void_, T17=boost::detail::variant::void_, T18=boost::detail::variant::void_, T19=boost::detail::variant::void_, T=TestClass]" 
temp.cu(17): here

1 error detected in the compilation of "/tmp/tmpxft_00005819_00000000-8_temp.cpp1.ii".

If I change boost/config/select_compiler_config.hpp

42 #elif defined __clang__ && !defined(__CUDACC__)

to

42 #elif defined __clang__

everything works well.

Moved from Trac.

Compile failures with char8_t by MSVC under /std:c++latest(C++20) mode

We've stumbled across some build failures in Boost\libs\config\test after implementing support for char8_t under /std:c++latest in the development version of Visual C++. Could you help look at this? Thanks in advance! Noted that this issue only found when compiles with unreleased vctoolset, that next release of MSVC will have this behavior.

Repro steps:

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git D:\Boost\src
2. open a VS 2017 x86 command prompt and browse to D:\Boost\src
3. set CL=/std:c++latest
4. .\bootstrap
5. .\b2 headers variant=release --build-dir=..\out\x86rel address-model=86
6. .\b2 variant=release --build-dir=..\out\x86rel address-model=86
7. .\b2 -j4 variant=release --build-dir=..\out\x86rel libs\config\test

Failures:
config_test.i
D:\Boost\src\libs\config\test\boost_no_unicode_literals.ipp(20): error C2440: 'initializing': cannot convert from 'const char8_t [1]' to 'const char *'
D:\Boost\src\libs\config\test\boost_no_unicode_literals.ipp(20): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

Boost failed when run config test with MSVC on Windows.

Boost failed with run time failure when run config test with MSVC on Windows, I use latest source on master branch. Could you please help take a look at this?

Reproduce steps:

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git D:\Boost\src
2. open a VS 2015 x86 command prompt and browse to D:\Boost\src
3. .\bootstrap
4. .\b2 headers variant=release --build-dir=..\out\Release --address-model=32
5. .\b2 variant=release --build-dir=..\out\Release --address-model=32
6. .\b2 -j4 variant=release --build-dir=..\out\x86rel libs\config\test

Expected result:
All tests passed

Actual result:
Testing bool (size 1) min: 0, max: 1
Testing char (size 1) min: -128, max: 127
Testing signed char (size 1) min: -128, max: 127
Testing unsigned char (size 1) min: 0, max: 255
Testing wchar_t (size 2) min: 0, max: 65535
Testing short (size 2) min: -32768, max: 32767
Testing unsigned short (size 2) min: 0, max: 65535
Testing int (size 4) min: -2147483648, max: 2147483647
Testing unsigned int (size 4) min: 0, max: 4294967295
Testing long (size 4) min: -2147483648, max: 2147483647
Testing unsigned long (size 4) min: 0, max: 4294967295
Testing long long (size 8) min: -9223372036854775808, max: 9223372036854775807
Testing unsigned long long (size 8) min: 0, max: 18446744073709551615
Testing __int64 (size 8) min: -9223372036854775808, max: 9223372036854775807
Testing unsigned __int64 (size 8) min: 0, max: 18446744073709551615

Testing float
IEEE-compatible: 1, traps: 0, bounded: 1, exact: 0
min: 1.17549e-38, max: 3.40282e+38
infinity: inf, QNaN: nan
hex value of max is: ffff7f7f
hex value of infinity is: 0000807f
hex value of qnan is: 0000c07f
hex value of snan is: 0100c07f

Testing double
IEEE-compatible: 1, traps: 0, bounded: 1, exact: 0
min: 2.22507e-308, max: 1.79769e+308
infinity: inf, QNaN: nan
hex value of max is: ffffffffffffef7f
hex value of infinity is: 000000000000f07f
hex value of qnan is: 000000000000f87f
hex value of snan is: 010000000000f87f

Testing long double
IEEE-compatible: 1, traps: 0, bounded: 1, exact: 0
min: 2.22507e-308, max: 1.79769e+308
infinity: inf, QNaN: nan
hex value of max is: ffffffffffffef7f
hex value of infinity is: 000000000000f07f
hex value of qnan is: 000000000000f87f
hex value of snan is: 010000000000f87f
main() should return report_errors()

EXIT STATUS: 3
====== END OUTPUT ======

set status=0
if %status% NEQ 0 (
    echo Skipping test execution due to testing.execute=off
    exit 0
)
 "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.exe"   > "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.output" 2>&1 
set status=%ERRORLEVEL%
echo. >> "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.output"
echo EXIT STATUS: %status% >> "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.output"
if %status% EQU 0 (
    copy "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.output" "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.run"
)
set verbose=0
if %status% NEQ 0 (
    set verbose=1
)
if %verbose% EQU 1 (
    echo ====== BEGIN OUTPUT ======
    type "..\out\x86rel\boost\bin.v2\libs\config\test\limits_test.test\msvc-14.1\release\threading-multi\limits_test.output"
    echo ====== END OUTPUT ======
)
exit %status%

add cxx17_deduction_guides

Boost.Histogram optionally supports deduction guides on compilers which support this. Please add a test for deduction guide support in the build system, so that corresponding unit tests are only compiled when the compiler supports deduction guides.

Compiling with Visual Studio 2017 (latest build)

I get this compiler warning:

5>Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message.

I am using the latest version of Boost. VS2017 is 15.5.3. How do I fix?

Thanks.

Missing BOOST_NO_TYPEID if not _CPPRTTI in boost/config/compiler/visualc.hpp

Looks like we forgot to define BOOST_NO_TYPEID if RTTI is disabled for MSVC (/GR- option).

I can prepare a PR.

Boost Config check for std::optional

Please can you add a check for the availability of C++17's std::optional. I think this would be really helpful because:

AFAIA, the major compilers all now have optional in std:: (rather than in std::experimental::)
I get the impression that people are fast adopting std::optional as a standard part of their type vocabulary.
I know at least one other ticket (ticket:12175) that's declining to support std::optional until Boost Config offers this feature test. 

I'm not sure about Boost Config's policy about how it interacts with the standard's ​feature testing macros (which include one for std::optional). If you expect other libraries to use those feature tests directly, please can you point me to documentation for that policy that I can we can point other library devs to?

Thanks very much.

Moved from Trac.

BOOST_HAS_PRAGMA_DETECT_MISMATCH with Clang defined by config #pragma but not supported.

I am compiling Boost.Math tests (using the jamfile) with Clang 6.0.0 on windows 10 and get this warning

In file included from ......\boost/function/function_base.hpp:21:
......\boost/type_index.hpp:37:20: warning: unknown pragma ignored [-Wunknown-pragmas]

pragma detect_mismatch( "boost__type_index__abi", "RTTI is used")

               ^

Clang (and GCC?) do not seem to provide this pragma.

In \modular-boost\libs\type_index\include\boost\type_index.hpp

at line 43

ifdef BOOST_HAS_PRAGMA_DETECT_MISMATCH

pragma detect_mismatch( "boost__type_index__abi", "RTTI is off - using CTTI")

end

(and attempts to suppress with -Wno-unknown-pragmas - elswhere reported to have no effect).

while I:\modular-boost\libs\type_index\include\boost\type_index.hpp says

// Detecting -fms-extension compiler flag assuming that _MSC_VER defined when that flag is used.
#if defined (_MSC_VER) && (clang_major > 3 || (clang_major == 3 && clang_minor >= 4))

define BOOST_HAS_PRAGMA_DETECT_MISMATCH

#endif

does not seem to give the expected non-define of BOOST_HAS_PRAGMA_DETECT_MISMATCH

BOOST_HAS_PRAGMA_DETECT_MISMATCH is defined, but using Clang 6.0.0 does not support this pragma.

However perhaps this is intentional and it is better to have this warning (whose significance, if any, I have yet to understand)?

Update for 15.5 preview

This was discussed here:

http://boost.2283326.n4.nabble.com/MSVC-15-5-support-td4699334.html

And has been requested for boost 1.66.0 as msvc 15.5 should be released about the same time.

add BOOST_FUNCTION_DEPRECATED

It would be great to have a cross-platform way give a deprecation warning at compile-time for pre-c++14 compilers. In C++14, there is [[deprecated]], but older compilers already supported this with compiler-specific extensions, see e.g.:

https://stackoverflow.com/questions/295120/c-mark-as-deprecated/21265197#21265197

If it is hard to do, maybe not worth investing the time, but it could be very useful.

[clang][Windows] Boost.Log does not compile (BOOST_SYMBOL_VISIBLE)

The commit 3b709bc breaks Boost.Log when compiling with clang on Windows.

To reproduce:

"C:\Program Files\LLVM\bin\clang++.exe" -fsyntax-only boost\boost\log\attributes\attribute.hpp -Iboost -std=c++2a

Error:

boost\boost\log\attributes\attribute.hpp:69:5: error: declaration of anonymous struct must be a definition
struct BOOST_LOG_NO_VTABLE BOOST_SYMBOL_VISIBLE impl :

This happens because (after aforementioned commit) BOOST_SYMBOL_VISIBLE expands to __attribute__((__visibility__("default"))) which is not recognized by clang on Windows.

Visual Studio 2017.3: "Unknown compiler version" and other issues

config/include/boost/config/compiler/visualc.hpp

Line 325 in b57df2a

#if (_MSC_VER > 1910)

This check fails on msvc-141 version provided by VS2017.3 (released today).

_MSC_VER is 1911 in this version.

[[no_unique_address]]

Hello,
it would be convenient, for use inside boost, to have a way to use the attribute [[no_unique_address]] when it is available. It could be a macro BOOST_ATTRIBUTE_NO_UNIQUE_ADDRESS, or maybe BOOST_ATTRIBUTE(XXX) that expands to [[XXX]] in C++11 and nothing in C++03 (it shouldn't be necessary to check for C++2a since compilers are supposed to ignore the attributes they don't know about), or any other way that is easy to use.

Wanted: Workaround for deduction guide detection on gcc

gcc-7 and gcc-8 both fail the deduction guide detection check.
gcc-7 (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
gcc-8 (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0

g++-7 -std=c++17 ../config/checks/std/cpp_deduction_guides_17.cpp 
../config/checks/std/cpp_deduction_guides_17.cpp:23:2: error: #error "Macro __cpp_deduction_guides had too low a value"
 #error "Macro __cpp_deduction_guides had too low a value"

g++-8 -std=c++17 ../config/checks/std/cpp_deduction_guides_17.cpp 
../config/checks/std/cpp_deduction_guides_17.cpp:23:2: error: #error "Macro __cpp_deduction_guides had too low a value"
 #error "Macro __cpp_deduction_guides had too low a value"

These compilers support deduction guides, but the value for __cpp_deduction_guides is 201606 or 201611, respectively.
https://gcc.gnu.org/projects/cxx-status.html#cxx17

Perhaps the threshold value can be lowered to 201611?

C++11 constexpr (N3268) is not fully implemented in GCC-4.6

@pdimov found that GCC-4.6 fails to compile this code

namespace ns {}

template <typename T>
constexpr T f(T t)
{
    using namespace ns; // using-directive or using-declaration
    return t;
}

int main ()
{
    (void)f(0);
}

and made a workaround in Boost.Range by removing BOOST_CONSTEXPR.

This means that GCC-4.6 does not implement some part (i.e. using-directives and using-declarations) of N3268, which is a last-minute fix towards C++11.

Would it make sense to #define BOOST_NO_CXX11_CONSTEXPR on GCC-4.6?
Boost.Unit uses this pattern extensively in <boost/units/cmath.hpp>.

BOOST_ATTRIBUTE_NODISCARD triggers -Wpedantic on clang-6

See issue on Godbolt

I am not quite sure what to do about this, there are several options. I think this is not our fault, clang is inconsistent here. My expectation is that when I compile with -std=c++14, a compiler should simply not accept the attribute. But clang-6 does accept it anyway which is why the configuration tests pick this up. However, when pedantic warnings are enabled, it warns about the usage.

So the general solution would be to run the configuration tests with -Wpedantic -Werror.

Should consider the value of __cplusplus for macro definations in boost/config/detail/suffix.hpp

Boost detects the availability of features by checking for the presence of the corresponding headers in boost/config/detail/suffix.hpp, but not checking the value of the __cplusplus macro.
This results in issues if we have multiple C++ versions built.

For example, if we have C++14 & C++17 built before building boost. That is, most of the C++17 headers are available.
Now we want to build boost with -std=c++14. That is, it is expected that boost should only use the C++14 functionality.
Howerver, boost reports following build errors:

In file included from ../libs/config/test/config_test.cpp:351:
../libs/config/test/boost_no_cxx17_hdr_string_view.ipp:19:14: error: no member named 'string_view' in namespace 'std'
using std::string_view;
~~~~~^

This is because, in boost/config/detail/suffix.hpp, BOOST_NO_CXX17_HDR_STRING_VIEW is not defined in this case.

#if !defined(__has_include)
#define BOOST_NO_CXX17_HDR_OPTIONAL
#define BOOST_NO_CXX17_HDR_STRING_VIEW
#define BOOST_NO_CXX17_HDR_VARIANT
#else
#if !__has_include()
#define BOOST_NO_CXX17_HDR_OPTIONAL
#endif
#if !__has_include(<string_view>)
#define BOOST_NO_CXX17_HDR_STRING_VIEW
#endif
#if !__has_include()
#define BOOST_NO_CXX17_HDR_VARIANT
#endif
#endif

This should be changed to something like:

#if !defined(__has_include) || __cplusplus < 201700
#define BOOST_NO_CXX17_HDR_OPTIONAL
#define BOOST_NO_CXX17_HDR_STRING_VIEW
#define BOOST_NO_CXX17_HDR_VARIANT
#else
...

Boost Config check for std::variant

Could you please add a check for the availability of C++17's std::variant?

This would be useful in the context of PR boostorg/serialization#148 that adds support for std::variant to Boost.Serialization. The tests need to be disabled when the variant header is not available.

CMake feature detection

As mentioned in https://lists.boost.org/Archives/boost/2018/10/243729.php I would be happy to implement this type of functionality.

Would a PR implementing the detection logic be acceptable? Or is someone already working on this?

Thanks,
Roger

Possibly incorrect check for compiler version

The below > comparison seems to be incorrect according to the comments within the file visualc.hpp

//
// last known and checked version is 19.11.25506 (VC++ 2017.3):
#if (_MSC_VER > 1911)
#  if defined(BOOST_ASSERT_CONFIG)
#     error "Boost.Config is older than your current compiler version."
#  elif !defined(BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE)
#     pragma message("Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message.")
#  endif
#endif

According to

//  Microsoft Visual C++ compiler setup:
//
//  We need to be careful with the checks in this file, as contrary
//  to popular belief there are versions with _MSC_VER with the final
//  digit non-zero (mainly the MIPS cross compiler).
//
//  So we either test _MSC_VER >= XXXX or else _MSC_VER < XXXX.
//  No other comparisons (==, >, or <=) are safe.

I stumbled on this due to the error given about an outdated compiler version.

Feature detection for std::size

For the Catmull-Rom PR, we require C++17 std::size. I'm currently simulating C++17 feature support with requires cxx17_if_constexpr, which seems to work well enough (though this failure makes the mind boggle). However, it might be nicer to have the exact feature.

boost-1.68.0: error: ignoring #pragma detect_mismatch

On NetBSD 8.99.24, gcc (nb2 20180327) 6.4.0, with boost from pkgsrc, gnucash 3.2 fails with boost-1.68.0 but did not fail with boost-1.67.0.
The gnucash error is:

In file included from /usr/pkg/include/boost/variant/variant.hpp:21:0,
                 from /usr/pkg/include/boost/variant.hpp:17,
                 from .../gnucash-3.2/libgnucash/engine/kvp-value.hpp:36,
                 from .../gnucash-3.2/libgnucash/engine/kvp-frame.hpp:87,
                 from .../gnucash-3.2/libgnucash/engine/test-core/test-engine-stuff.cpp:39:
/usr/pkg/include/boost/type_index.hpp:37:0: error: ignoring #pragma detect_mismatch  [-Werror=unknown-pragmas]
 #           pragma detect_mismatch( "boost__type_index__abi", "RTTI is used")
 

When building boost, I see:

boost/config/user.hpp:#define BOOST_HAS_PRAGMA_DETECT_MISMATCH

the symbol is defined, but it seems the compiler does not like it anyway.
I don't understand the build system well enough to see where/why this is defined, but something's going wrong.

boost_no_com_value_init.ipp: out of bounds array access

$ clang++ -I../../.. -fsanitize=undefined config_test.cpp && a
boost_no_com_value_init.ipp:429:11: runtime error: index 4 out of bounds for type 'char const[4]'
boost_no_com_value_init.ipp:443:11: runtime error: index 7 out of bounds for type 'char const[7]'

cstdint.hpp is lacking SIZE_MAX

Header cstdint.hpp is lacking the constant SIZE_MAX that is normally defined in stdint.h.

Since cstdint.hpp is supposed to be a portable C++ port of the standard C99 header stdint.h, I believe that missing constant should be added.

Moved from Trac

VS2017 update 3 support structured bindings

We can use _MSC_VER == 1911 to check update 3
https://blogs.msdn.microsoft.com/vcblog/2017/05/10/c17-features-in-vs-2017-3/

Warning whe compiling with -Wundef on clang

When compiling with -Wundef on clang we get the following warning

/xxx/modular-boost3/boost/type_traits/is_nothrow_move_constructible.hpp:30:79: warning: 'BOOST_GCC_VERSION_WORKAROUND_GUARD' is not defined, evaluates to 0 [-Werror,-Wundef]
#elif !defined(BOOST_NO_CXX11_NOEXCEPT) && !defined(BOOST_NO_SFINAE_EXPR) && !BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40800)
                                                                              ^
/Users/viboes/github/modular-boost3/boost/config/workaround.hpp:244:10: note: expanded from macro 'BOOST_WORKAROUND'
       ((symbol ## _WORKAROUND_GUARD + 0 == 0) &&     \
         ^
<scratch space>:222:1: note: expanded from here
BOOST_GCC_VERSION_WORKAROUND_GUARD
^

This is because BOOST_GCC_VERSION_WORKAROUND_GUARD is not defined and used in an expression.

The following fixes the issue.

#ifndef BOOST_GCC
#define BOOST_GCC_WORKAROUND_GUARD 1
#define BOOST_GCC_VERSION_WORKAROUND_GUARD 1
#else
#define BOOST_GCC_WORKAROUND_GUARD 0
#define BOOST_GCC_VERSION_WORKAROUND_GUARD 0
#endif
``

cstdint.hpp:303:195: warning: use of C++11 long long integer constant

While building Boost.Uuid through Appveyor for cygwin with cxxflags=-std=c++03, I am seeing this warning over 1,500 times:

./boost/cstdint.hpp:303:195: warning: use of C++11 long long integer constant [-Wlong-long]
 #    elif (defined(ULLONG_MAX) && ULLONG_MAX == 18446744073709551615ULL) || (defined(ULONG_LONG_MAX) && ULONG_LONG_MAX == 18446744073709551615ULL) || (defined(ULONGLONG_MAX) && ULONGLONG_MAX == 18446744073709551615ULL)
                                                                                                                                                                                                   ^

See build job:
https://ci.appveyor.com/project/jeking3/uuid/build/1.0.114-develop/job/ws6sqg5vvsc20j1b

Request new config macro to detect if basic_iostream has operator void* or not

I'm looking for a Boost.Config macro that will allow this to build (on Windows too):

#if __cplusplus < 201103L
    BOOST_CHECK_MESSAGE(0 == str.operator void* (),
            "stream does not report failure by operator void* (up to C++11)");
#else
    BOOST_CHECK_MESSAGE(0 == str.operator bool (),
            "stream does not report failure by operator bool (as of C++11)");
#endif

BOOST_NO_CXX17_STD_INVOKE broken

BOOST_NO_CXX17_STD_INVOKE does not work on g++-6.4.0 or Apple LLVM version 9.1.0 (clang-902.0.39.1) in C++1z mode, due to the fact that their implementation of C++17 is incomplete.

Help detect if I can default a move constructor

The following program fails to compile on GCC 4.4 and MSVC 12:

#include <boost/config.hpp>

#if (!defined BOOST_NO_CXX11_DEFAULTED_FUNCTIONS) && (!defined BOOST_NO_CXX11_RVALUE_REFERENCES)
static_assert(true, "***");
#else
static_assert(false, "***");
#endif

struct X
{
    X(X&&) = default;
};

int main() {}

Here is a Wandbox demo: https://wandbox.org/permlink/X5m8jmU18Fvo2Y86

Boost.Config detects support for rvalue references and for defaulted functions, but defaulting a move constructor as defaulted is still a compiler error. Can we define a config macro for that?

Some C++17 config macros missing from documentation

BOOST_NO_CXX17_INLINE_VARIABLES is not listed anywhere in the docs, but exists in the code.

There are probably others.

Most of BOOST_HAS_TR1_* macros are ghosts

I was going to use BOOST_HAS_TR1_FUNCTION to detect std::function availability, but find out that most of BOOST_HAS_TR1_* macros presented only in docs (17 documented and only 6 have any traces in the code).

#define BOOST_HAS_TR1_HASH
#define BOOST_HAS_TR1_TYPE_TRAITS
#define BOOST_HAS_TR1_UNORDERED_MAP
#define BOOST_HAS_TR1_UNORDERED_SET
#define BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG
#define BOOST_HAS_TR1_COMPLEX_OVERLOADS

Am I missing something?