c++17

The code below fails to compile with gcc 7.1.0, which complains about providing the wrong number of template arguments in the second line of main. This version of GCC is supposed to implement template argument deduction of class templates. I think the compiler should be able to deduce the class template argument T2 for Bar, which means that I shouldn't have to explicitly specify both arguments ( Bar<int, int> ) given paragraph 17.8.1.3 of the C++17 draft which says, "Trailing template arguments that can be deduced (17.8.2) or obtained from default template-arguments may be omitted from the

Imagine we have a header foo.h containing the following: #ifndef FOO_H_ #define FOO_H_ namespace foo { constexpr std::string_view kSomeString = "blah"; } #endif // FOO_H_ Is foo::kSomeString guaranteed to have internal linkage in any translation unit that includes foo.h ? Does this vary between C++11 and C++17? In the draft standard [basic.link]/3 says A name having namespace scope has internal linkage if it is the name of [...] a non-inline variable of non-volatile const-qualified type that is neither explicitly declared extern nor previously declared to have external linkage [...] But I don

This is a follow up of this question . As mentioned in the comments to the answer: An inline variable has the property that - It has the same address in every translation unit . [...] Usually you achieved that by defining the variable in a cpp file, but with the inline specifier you can just declare/define your variables in a header file and every translation unit using this inline variable uses exactly the same object. Moreover, from the answer itself: While the language does not guarantee (or even mention) what happens when you use this new feature across shared libraries boundaries, it does

Template class std::iterator is set to be deprecated in C++17. Why so? It has been a handy way to make sure std::iterator_traits works, especially if you can make use of the default template arguments. Is there some other way of doing it in C++17? Barry From the proposal that suggested its deprecation : As an aid to writing iterator classes, the original standard library supplied the iterator class template to automate the declaration of the five typedefs expected of every iterator by iterator_traits. This was then used in the library itself, for instance in the specification of std::ostream

Please consider the following code snippet: template<class Tuple> class vector { public: typename Tuple::size_type size() const noexcept(noexcept(m_elements.size())) { return m_elements.size(); } private: Tuple m_elements; }; class tuple { public: using size_type = std::size_t; size_type size() const { return 0; } size_type size() noexcept { return 0; } }; int main() { vector<tuple> x; static_assert(noexcept(x.size()), "x.size() might throw"); return 0; } Is the use of the member variable m_elements inside the noexcept specifier legal? GCC 5.2 (C++17) yields the compiler error m_elements was

Since the extended versions of constexpr (I think from C++14) you can declare constexpr functions that could be used as "real" constexpr, that is, the code executed at compile time or can behave as inline functions. So when can have this program: #include <iostream> constexpr int foo(const int s) { return s + 4; } int main() { std::cout << foo(3) << std::endl; const int bar = 3; std::cout << foo(bar) << std::endl; constexpr int a = 3; std::cout << foo(a) << std::endl; return 0; } Of course, the result is: 7 7 7 so far so good. So my question is: is there a way (possibly standard) to know in

I saw std::result_of is being deprecated in C++17. What is the reason for std::result_of deprecated in C++17? Also I would like to know the difference between std::result_of and std::invoke_result . T.C. already provided the obvious link, but perhaps the most horrific reason bears repeating: result_of involved forming the type F(Arg1, Arg2, ...) not for a function of those types returning F but for a function of type F accepting those types. (After all, the return type is the result of, well, result_of , not the input!) Aside from the adjustments associated with forming the function type, the