Indeed, for each point I was expecting a before /after example 😀 come on!

I did this for a few samples, I hoped that would be good enough :)
You can try it yourself and run/edit/compile code inside the post.
If you write more samples I'm happy to include them in the main article! :)

I think that this is a bit of syntatic sugar that is unnessesary. It just prevents your code from being backwards compatible and it isn't really so much more understandable than the normal x; if (y) {z} form

Hi, what is the purpose of forward<args>(args) in the print and folds example? I replaced it with just args and the example worked.

The purpose is to preserve the lvalue or rvalue identity of the argument.

Your fibonacci example doesn't need to be a template function.

None of the C++17 features is really necessary, everything could be done with C++03 as well.

Everything could be done in assembly after all, so why are you using C++?
This is exactly your logic. These features make it easier and safer to do certain stuff.

Are there any plans to do this for switch as well? Should make the tuple example even cleaner.

r/programming comments: https://www.reddit.com/r/pr...

Overall its good - but would like to see the removal of the 'depreciation' of autoptr, not that its good (its not!)

But autoptr isrequired for backwards compatibility with older code, one of the big advantages of C++ and library is forwards compatibility. Yes it can be replaced by the new and better alternatives, but its still there in old tied and tested code that will no longer compile - sheer and utter vandalism by some C++ purist zealot to make a point.

Yes - We know autoptr its not perfect and it really shouldn't be used, just as we know raw pointers are a bad idea - but they are still there for good reasons - compatibility.

auto_ptr is removed, was deprecated in C++11 and now in C++17 it's removed: see http://www.bfilipek.com/201...

Yes I know and that's what wrong!!!!!
It breaks backwards compatible with legacy code - most silly idea yet to come out of the ISO C++ committees!

A totally unnecessary risk to older C++ code out there, code that has proven itself reliable and good for years now has to be modified.
If the C++ ISO group responsible doesn't understand this, then they really do need to resign and get some real world experience for a while!

The issue is so serious that I know of a number of companies that are saying they are not going to use C++ 17 due to the cost and risk of modifying large amounts of legacy code (not to mention testing etc.).

Yes - crazy to miss out on the new features, but not as crazy as the people that screw up backwards compatibility for legacy code, and for no good reason other than being a C++ 17 purist (and that is not meant to be a complement!).
What next - ban native pointers (a lot bigger source of problems than auto_ptr!)

They could have at least left it in via a separate include file or similar that had to be explicitly defined/included, so it would not be going into new code.

Native pointers cannot be banned because of iterators and future Ranges specifications and memcpy, memmove, memset zoo. If you want to allocate on heap, then you use smart pointers for ownership. There are features that are questionable and sometimes get removed, but there are others that a good developer that knows his C++ should know they won't be removed since they are the best solution for some problem.

"The issue is so serious that I know of a number of companies that are saying they are not going to use C++ 17 due to the cost and risk of modifying large amounts of legacy code (not to mention testing etc.)."
I can not follow this point. If you really still want to use auto_ptr, you can simply copy the auto_ptr implementation from your pre-C++-17 compiler (which is just a few lines of code), put it into a header file and include this file in your C++ 17 project. Not costly, not risky, no need to modify large amounts of legacy code, not much testing effort... And what etc.?

That's still called modifying code instead of relying on the QA and testing of compiler and libraries
C++ gives users the ability to shoot themselves in the foot in so many ways (with great power comes great responsibility!) , so why prevent users who need to use the auto_ptr in legacy code.
The recent April Fools prank about removing raw pointers was unfortunately to close to the truth considering some of the self righteous idiots on the ISO committee!

If you take the auto_ptr implementation of a decent major compiler and use this in your C++ 17 project, which kind of QA issues would you expect? auto_ptr is simple, out in the field for many years, used millions of times and has for sure undergone more QA checks than you can think of.

That's the point, auto_ptr is QA and well tested so why remove it, even a copy and paste comes with a risk, so why do developers and users have to take a risk to satisfy some self centered ISO committee members already inflated ego.

Indeed I was expecting a before / after example! Come on blogger!

I tried this out on MS Visual Studio, and unless I misunderstood - C++17 seems FAR MORE LENIENT than described here:

//MyInlineVariablesTest.h

#pragma once

class MyInlineVariablesTest
{
public:
inline MyInlineVariablesTest() = default;
inline ~MyInlineVariablesTest() = default;
inline static int value1_i = 1;
inline static string value2_str = "value_2";
};

// My test function:
#include "MyInlineVariablesTest.h"
void test_InlineVariables(void) {
// Dunno: inline static variables seem FAR MORE FORGIVING/FLEXIBLE than what the article describes.
// I managed to get the entire class into a '.h' file, no accompanying '.cpp', and NO syntactic hassle.

MyInlineVariablesTest myInlineVariablesTest1;
MyInlineVariablesTest myInlineVariablesTest2;

// STATIC INT
cout << "(1) myInlineVariablesTest1.value1_i==" << myInlineVariablesTest1.value1_i <<
" myInlineVariablesTest2.value1_i==" << myInlineVariablesTest2.value1_i << endl;

myInlineVariablesTest1.value1_i = 99;
cout << "assigned 'myInlineVariablesTest1.value1_i = 99;', and now: ..." << endl;
cout << "(2) myInlineVariablesTest1.value1_i==" << myInlineVariablesTest1.value1_i <<
" myInlineVariablesTest2.value1_i==" << myInlineVariablesTest2.value1_i << endl;

MyInlineVariablesTest::value1_i = 100;
cout << "assigned 'MyInlineVariablesTest::value1_i = 100;', and now: ..." << endl;
cout << "(3) myInlineVariablesTest1.value1_i==" << myInlineVariablesTest1.value1_i <<
" myInlineVariablesTest2.value1_i==" << myInlineVariablesTest2.value1_i << endl;

// STATIC STRING
cout << "(1.1) myInlineVariablesTest1.value2_str.c_str()==" << myInlineVariablesTest1.value2_str.c_str() <<
" myInlineVariablesTest2.value2_str.c_str()==" << myInlineVariablesTest2.value2_str.c_str() << endl;

myInlineVariablesTest1.value2_str = "value2_mod1";
cout << "assigned 'myInlineVariablesTest1.value2_str = \"value2_mod1\";', and now: ..." << endl;
cout << "(2.1) myInlineVariablesTest1.value2_str.c_str()==" << myInlineVariablesTest1.value2_str.c_str() <<
" myInlineVariablesTest2.value2_str.c_str()==" << myInlineVariablesTest2.value2_str.c_str() << endl;

MyInlineVariablesTest::value2_str = "value2_mod2";
cout << "assigned 'MyInlineVariablesTest::value2_str = \"value2_mod2\";', and now: ..." << endl;
cout << "(3.1) myInlineVariablesTest1.value2_str.c_str()==" << myInlineVariablesTest1.value2_str.c_str() <<
" myInlineVariablesTest2.value2_str.c_str()==" << myInlineVariablesTest2.value2_str.c_str() << endl;
}

MY OUTPUT:

(1) myInlineVariablesTest1.value1_i==1 myInlineVariablesTest2.value1_i==1
assigned 'myInlineVariablesTest1.value1_i = 99;', and now: ...
(2) myInlineVariablesTest1.value1_i==99 myInlineVariablesTest2.value1_i==99
assigned 'MyInlineVariablesTest::value1_i = 100;', and now: ...
(3) myInlineVariablesTest1.value1_i==100 myInlineVariablesTest2.value1_i==100
(1.1) myInlineVariablesTest1.value2_str.c_str()==value_2 myInlineVariablesTest2.
value2_str.c_str()==value_2
assigned 'myInlineVariablesTest1.value2_str = "value2_mod1";', and now: ...
(2.1) myInlineVariablesTest1.value2_str.c_str()==value2_mod1 myInlineVariablesTe
st2.value2_str.c_str()==value2_mod1
assigned 'MyInlineVariablesTest::value2_str = "value2_mod2";', and now: ...
(3.1) myInlineVariablesTest1.value2_str.c_str()==value2_mod2 myInlineVariablesTe
st2.value2_str.c_str()==value2_mod2

I think the for (auto &p : itemsToAdd) is better by: for (const auto &p : itemsToAdd)