News for hackers. Stuff that matters.
Re:A Perspective on C++ Standardization in 2018 by chris_wot on Saturday December 29, 2018 @02:38AM (#18782492)
What, precisely, are the warts that folks want to get rid of in C++ but cannot?
Re:A Perspective on C++ Standardization in 2018 by hellofunk on Saturday December 29, 2018 @04:04AM (#18782753)
Depends who you talk to. Here’s one take by the great Scott Meyers:

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

Re:A Perspective on C++ Standardization in 2018 by Ace17 on Saturday December 29, 2018 @05:49AM (#18783041)
The preprocessor: Bjarne Stroustrup has been willing to get rid of it for a long time. C++20 modules are a step in this direction. However - as pointed out by John Lakos - you still need macros to build zero-cost logging facilities.
Re:A Perspective on C++ Standardization in 2018 by frabert on Saturday December 29, 2018 @07:51AM (#18783363)
I don't think that's necessarily true, using constexpr facilities you could make a function do nothing according to a compile-time variable value
Re:A Perspective on C++ Standardization in 2018 by Ace17 on Saturday December 29, 2018 @01:09PM (#18784852)
I agree ; however, the tricky part - I believe - is not computing the message string in case you're not going to print/record it.
Re:A Perspective on C++ Standardization in 2018 by xamolxix on Saturday December 29, 2018 @11:00AM (#18784151)
Is IO allowed in constexpr functions?
Re:A Perspective on C++ Standardization in 2018 by justbuchanan on Saturday December 29, 2018 @11:27AM (#18784281)
I don't think so, but for zero-cost logging you just need the conditional for your branch to be constexpr. If the branch is known not to be taken at compile time, the compiler can just throw it away.

Something like:

  void MyDebugLog(text) {
    if (<constepxr check if logging enabled>) {
      // actually log...
    }
  }
Re:A Perspective on C++ Standardization in 2018 by Ace17 on Saturday December 29, 2018 @01:07PM (#18784840)
Corresponding citation from John Lakos about why macros could be necessary: https://www.youtube.com/watch?v=K_fTl_hIEGY&t=3140
Re:A Perspective on C++ Standardization in 2018 by slavik81 on Saturday December 29, 2018 @04:06AM (#18782755)
Just off the top of my head, it would be nice to remove std::initializer_list from the standard to make uniform initialization truly uniform, and to remove to the 'explicit' keyword to make it the default behaviour.

There's also stuff from C that can be surprisingly complicated, like integer promotion rules, but if you change that sort of thing you might as well design a new language from scratch.

Re:A Perspective on C++ Standardization in 2018 by will4274 on Saturday December 29, 2018 @09:31AM (#18783714)
The biggest one for me is the preprocessor. The preprocessor is THE reason C++ has such horrendous compilation times compared to basically any other language.

Others have mentioned uniform initialization, which I definitely agree with.

Re:A Perspective on C++ Standardization in 2018 by xamolxix on Saturday December 29, 2018 @11:02AM (#18784164)
I believe templates make for slower compilation times.
Re:A Perspective on C++ Standardization in 2018 by will4274 on Saturday December 29, 2018 @08:43PM (#18786832)
These are one and the same issue. Templates have to be in headers and cannot be in source. The preprocessor requires that headers be repeatedly reparsed and recompiled. So, templates get repeatedly recompiled.
Re:A Perspective on C++ Standardization in 2018 by pjmlp on Saturday December 29, 2018 @09:11AM (#18783610)
From my tiny spot on the metaverse, copy-paste compatibility with C's security flaws.