C++17 and its Technical Specifications

Re:C++17 and its Technical Specifications by vardump on Thursday March 03, 2016 @02:08PM (#11219157)

When will there be a C++XX that will actually remove bad features? Of course with a migration plan and tools.

C++ standard is pretty big, I don't personally know anyone who really knows C++.

I write C++ as my day job.

[ Parent | on HN ]

Re:C++17 and its Technical Specifications by santaclaus on Thursday March 03, 2016 @02:19PM (#11219241)

Scott Meyers (of Effective C++ fame) has a great blog post on breaking backwards compatibility [1]. Unfortunately, he views it as a 10 year process.

[1] http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in...

[ Parent | on HN ]

Re:C++17 and its Technical Specifications by jzwinck on Thursday March 03, 2016 @02:13PM (#11219193)

There have been deprecations like auto_ptr and gets(). But I assume you're looking for more.

You aren't going to get it. C++ is just not that language. It isn't going to have a Python 3 moment. Nor should it.

I for one am glad to be able to upgrade to new versions of the language without having to rewrite much.

[ Parent | on HN ]

Re:C++17 and its Technical Specifications by Noughmad on Thursday March 03, 2016 @02:58PM (#11219545)

Complete breaking is never going to happen. What can be done is adding compiler switches which enforce some kind of "strict" or "modern" mode. Something close to "-Wall -Werror", but with errors explicitly for the deprecated/bad features.

[ Parent | on HN ]

Re:C++17 and its Technical Specifications by StephanTLavavej on Thursday March 03, 2016 @06:13PM (#11220810)

Actually, my proposal to remove auto_ptr etc. from C++17 was accepted: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n419...

[ Parent | on HN ]