c++17

I seem to have found something that Clang and GCC disagree on. Here's the code: int main() { if constexpr (2) {} } This successfully compiles with GCC 7.4.0, but it fails with Clang 7.0.0 with this error message: test.cpp:3:17: error: constexpr if condition evaluates to 2, which cannot be narrowed to type 'bool' [-Wc++11-narrowing] if constexpr (2) {} ^ 1 error generated. cppreference doesn't seem to mention "narrowing", so this seems like a Clang bug, but I'm not entirely certain. If this is a bug with either compiler, has it already been reported? StoryTeller - Unslander Monica Clang is

Consider this example: struct T { }; struct S { operator T(); }; S s; T t = s; [dcl.init] will take us to [over.match.copy] which will find the conversion function operator T() . But are we done at that point, or do we have to invoke T(T&& rhs) , binding rhs to the return of operator T() via [dcl.init.ref]? Are there any differences with regards to the answer to this question between C++11 and C++1z? This falls under [dcl.init]/17.6.3 , which is pretty clear about what happens after overload resolution selects the conversion function: The function selected is called with the initializer

Trying to get more familiar with C++17, I've just noticed std::visit : template <class Visitor, class... Variants> constexpr /*something*/ visit(Visitor&& vis, Variants&&... vars); Why does std::visit not take a single variant, but rather any number of variants? I mean, you can always take some standard library function and have it take multiple parameters with the same role, working on all of them (e.g. std::find() for multiple elements in a container); or you could be taking multiple visitors and using them on the same variant. So, why this specific 'variadification'? To make multiple

It looks like we can safely use std::cout object in constructors of objects with static storage duration as stated in this question . However, I'm not entirely sure that we can safely use them in case of variable templates: #include <iostream> template<class T> T x = T{}; void foo() { class Test { public: Test() { std::cout << "Test::Test\n"; } }; Test t = x<Test>; } int main() { std::cout << "main\n"; } This code crashes in clang ( live example ) and I'm not sure whether it's a bug or not. As explained in that question, one effect of #include <iostream> is the equivalent of defining a global

I need to replace the /std:c++14 flag of an INTERFACE target (header-only library) with /std:c++17 . CMake doesn't support setting C++17 flags in VS directly yet (see How to enable /std:c++17 in VS2017 with CMake ) so I need to manually replace it. However get_target_property(my_compile_flags mylib COMPILE_OPTIONS) to retrieve the list of currently set flags to then subsequently replace /std:c++14 with /std:c++17 doesn't work: INTERFACE_LIBRARY targets may only have whitelisted properties. The property "COMPILE_OPTIONS" is not allowed. You can set them however via target_compile_features(...)

I have two pointers: pA and pB. They points to two big hash map objects. when the hash map pointed by pB is updated completely, I want to swap pB and pA. In C++ 17, how to swap them fast and thread safe? Atomic? I am new to c++ 17. Atomic wait-free exchange of 2 pointers can be implemented in the following manner: #include <atomic> #include <cstdint> #include <cassert> template<class T> class Pointers2 { uintptr_t const ab_; std::atomic<uintptr_t> a_; public: Pointers2(T* a, T* b) : ab_(reinterpret_cast<uintptr_t>(a) ^ reinterpret_cast<uintptr_t>(b)) , a_(reinterpret_cast<uintptr_t>(a)) {} T*

Abstract: Imagine a problem of the following form: One has to invoke multiple specific member functions with the same parameters on a list of functors. That makes a good problem to solve with an interface (runtime_interface, in other words a requirement of functions that those functors have to implement). The Problem I would like to discuss is the case where the list of functors is known at compile time, but might be subject to change during the further development process. Because in this case if implemented like that one is paying the runtime overhead even though all the functions to be