10 ms·

C++ : if constexpr isn't broken

74 points by Bl4ckb0ne 8y ago

roywiggins 8y ago
"a somewhat more awkward and uglier, yet slightly more correct way... all the functionality is right there. We’re not missing anything" might as well be C++'s motto :)
- aassddffasdf 8y ago
  "The amount of things you have to know in C++ is arguably a bit larger." Arguably, lol.
  - nivexous 8y ago
    In Bitcoin SV, there is a saying "devs gotta dev" to refer to the mass of crypto developers that add unnecessary complexity to their coins to solve minor or even nonexistant problems while not seeing the bigger (usually economic) picture. Everyone wants to make their mark on the space and there aren't enough leaders to direct the energy. C++ looks to be doing the same and not able to see the impact this will have on adoption. Oh well. I personally moved from C++ to Rust last year and haven't looked back.
    - neutronicus 8y ago
      I disagree - I work in high-performance computing and I think in our case the complexity of C++ is actually mirroring that of the problem domain. Nothing else gives us the level of abstraction that C++ does, while still offering convenient ways to specify low-level performance semantics. I think for a while Fortran was pulling ahead for large-scale numerical computing, but the mess of different options for parallelism (and also I think in our case a profileration of algorithm choices that made not just polymorphism but the explicit distinction between polymorphism and templates more important for code architecture) have brought C++ back into the limelight. I know that some competitors in our space have a Fortran codebase and they essentially had to hack together C++ Templates as part of their build process (i.e. pre-process a template file and generate multiple sources which are then compiled).
      - SamReidHughes 8y ago
        Looking at some C++ extension proposals, many are definitely a case of "devs gotta dev." Fortunately most of these don't have a chance in hell of making it in.
        VHRanger 8y ago
        Yeah Stroustrup put his foot down this year on whacky proposals.
      - carlmr 8y ago
        I agree that in your case C or C++ is probably the way to go (I usually favor C, because while it affords less options for abstractions it also doesn't give so many possibilities to shoot yourself in the foot in unimaginable ways (still enough mind you)). Your parent poster is also right. Rust offers a lot of safety guarantees, a modern, well-designed language around it, package management, test and benchmarking integration, and extremely good type safety, while still mostly having zero cost abstractions for many things. If your goal is performance, control and safety, Rust is a much better choice than either C or C++. I'm still hopeful that it shall become the next big embedded language (mostly processor support missing here, but thanks to LLVM there's hope), especially since we haven't seen any other good attempt at GCless computing (no GC is pretty important for real-time systems). But I must admit that with C++ you can probably eke out a few % more performance. The thing is though that with Rust, for 99% of projects where performance and no-GC is important, will be fast enough, especially due to safe abstractions, often faster than C++. One example is if you have a lot of text processing to do. Often you can reuse a lot of the strings. In Rust you can safely handle this due to the borrow checker. Avoiding allocation of new strings is pretty much the biggest performance problem for most string processing. Rust gives you a lot of safety when it comes to multithreading as well. It's perfect for creating little servers and using all your processors for performance. These two together, and the lack of 2-3 day debugging sessions where you trace down that one tiny memory bug in C++, make Rust the biggest contender to replace C++. Of course if you only care about performance. C or C++ is probably still a slightly better choice, slightly.
- carlmr 8y ago
  It's already there, but it's really ugly and hard to read, would be my conclusion from this.
- paulddraper 8y ago
  "And if we are missing it, let's add it".
- gHosts 8y ago
  Yup. And while the rest of the world knew how to find a file size... how long was it before C++ cleaned that very very simple corner up? And if you look under the hood at the implementation of std::conditional.... I feel ill. The thing I like about Alexandrescu is he invented this meta programming stuff... super super super clever magic... ...and then backed away saying it shouldn't have to be so hard, we shouldn't need magic to program.
wyldfire 8y ago
Slides from Alexandrescu's referenced talk [1]. [1] http://erdani.com/MeetingC++2018Keynote.pdf http://erdani.com/MeetingC++2018Keynote.pdf
greesil 8y ago
I think I just got used to C++11. What is this dark magic?
- felixguendling 8y ago
  If you refer to `if constexpr`: There is no dark magic. Most of it is already possible with C++11 meta programming (i.e. with std::enable_if [0]). However, it's much more readable now (and it's more fun to write :D). I think we're on a good way that compile time programming will be more easily accessible. [0] https://en.cppreference.com/w/cpp/types/enable_if https://en.cppreference.com/w/cpp/types/enable_if
- gpderetta 8y ago
  Most of this stuff was possible in C++03. Newer standards only make it more convenient and (arguably) saner.
mattnewport 8y ago
I had similar thoughts when looking through the slides for Andrei's talk. A main argument in favor of static if over the mechanisms C++ offers to do the same things seems to be familiarity of if statements but having scope not be respected is such an unintuitive difference for anyone with experience in curly braces languages that it seems like a net loss in clarity to me. It looks more like using macros for conditional compilation. Overuse of if statements is generally something of a code smell and tends to make code harder to follow. To my taste the C++ way of doing things is generally preferable as a result even if more verbose. Given this is probably somewhat a matter of taste it is hard to justify changing C++ to match the D way IMO.
mark-r 8y ago
Why is it every time I see a new article about C++ features my eyes glaze over? Am I just getting old, or has C++ jumped the shark?
- moron4hire 8y ago
  I had a similar feeling. As a long-time C# programmer (how old is C#? That many years), I look at this and get really wide-eyed, "how is that at all a good idea?!" A lot of these features seem like ways to hack around the fact that C++ templates are not generics, they are literally templates for writing copies of classes. It seems like features like this are going to make code size explode. A lot of the examples also seem very smelly from an OOP perspective. We should one class be able to have different fields depending on template parameters? That seems like something one should do in a subclass.
  - mattnewport 8y ago
    I'm very familiar with C++ and C# and overall I find I like C++ a lot better. There are a few nice convenience features of C# but knowing both languages I tend to find whenever they differ I feel like C++ made the better design choice. And C# going all in on OOP is a part of that. It's reasonably clear now that OOP was mostly a big mistake and a dead end. C++ is less infected by going all in on it as it has always been a multi paradigm language.
  - adrianN 8y ago
    I'm not sure what you mean by generics if you think that C++ templates are not a kind of generics. Do you prefer that everything happens at runtime? Similarly, subclasses as opposed to templates carry a runtime cost. Virtual function calls are not free. Why pay that cost if you can deduce the right code from the types at compiletime? Besides, and this is probably a matter of opinion, I find code hard to follow that uses inheritance heavily.
    - Retra 8y ago
      By "generics", I presume they mean template parameters which are checked at declaration, not at use.
cjhanks 8y ago
I agree with this blog writer. Allowing typedefs to cross static if boundaries would be a major change to the way I read code. Unless there's a more substantive example demonstrating why using the existing metaprogramming is insufficient, its benefits are imo outweighed by its cost.
- renox 8y ago
  Well you already have to remember that 'if' introduces a scope but '#if' doesn't..
  - cjhanks 8y ago
    I guess that's true. But I can't remember the last time I have used `#if` aside from header guards and optimization paths. So they do exist, but I almost never do this.
choeger 8y ago
Oh my. If only C++ would have used proper macros from the start...
- adev_ 8y ago
  There is nothing as "a proper macro". There is proper meta-programming support or a badly design language.
  - choeger 8y ago
    A macro is a metal-level abstraction. So proper macros require proper metaprogramming support. And, I would argue, the other way around.
    - adev_ 8y ago
      And I would argue that a Macro is external language put on top of your language as a patch (hack), when your language is not expressive enough for genericity. Then yes, there is nothing as "proper" Macro. There is just an attempt to fix a limited language in the first place. And it is something that C++ arrived to solve ( not that badly ) currently.
- gumby 8y ago
  I discussed this once with Stroustrup. He mourned that the word "macro" had been "polluted" (his word, though I completely agreed) by the preprocessor and said "templates was the best we could do within the constraints of C". This was in the mid 90s and things are a lot better these days but still, I had better macro support writing Lisp in the 1970s.
  - choeger 8y ago
    I am ready to believe that hygienic macros would have been difficult, but just using lisp macros should have been straightforward. Tbh, I think that templates were an adhoc, amateurish design decision.
JabavuAdams 8y ago
I used to be a C++ guy from the early 90s 'till about 2010. Every few months, I think "I should really learn the new C++ hotness", and then I read something like this. It's like a bunch of priests arguing about how best to fit a bunch of ugly angels on a pointless pin. It just feels so pointless. If you must use C++, just use another language to generate the C++. All this template mumbo jumbo. Who says your meta-programming language has to be the same as your target language? I used to spend some time looking for the perfect vector (as in linear-algebra) library. Templatized for vector dimension, data-type, blah blah blah. Dude, just use Python to generate it. Duplication doesn't violate DRY if the duplication is generated from a single higher-level source. Doing meta-programming in C++ is a really limited way of thinking.
- nealabq 8y ago
  > fit a bunch of ugly angels on a pointless pin. It just feels so pointless. A pointless pin would indeed be pointless.
- mattnewport 8y ago
  I don't think anyone on the C++ committee is proposing banning you from generating C++ code with Python. I also doubt anyone who's interested in C++ metaprogramming has failed to consider the possibility of doing codegen via other means. In light of these facts what seems rather pointless is your comment.
- flukus 8y ago
  > Who says your meta-programming language has to be the same as your target language? I'd lay blame at IDE's and they way the take over the build system along with intellisense. They don't play well with anything generated before the compile step. Even adding a build step is and alien concept to many, so we end up with the build step shoe horned into languages.

74 points by Bl4ckb0ne 8y ago

"a somewhat more awkward and uglier, yet slightly more correct way... all the functionality is right there. We’re not missing anything" might as well be C++'s motto :)

aassddffasdf 8y ago
"The amount of things you have to know in C++ is arguably a bit larger." Arguably, lol.
- nivexous 8y ago
  In Bitcoin SV, there is a saying "devs gotta dev" to refer to the mass of crypto developers that add unnecessary complexity to their coins to solve minor or even nonexistant problems while not seeing the bigger (usually economic) picture. Everyone wants to make their mark on the space and there aren't enough leaders to direct the energy. C++ looks to be doing the same and not able to see the impact this will have on adoption. Oh well. I personally moved from C++ to Rust last year and haven't looked back.
  - neutronicus 8y ago
    I disagree - I work in high-performance computing and I think in our case the complexity of C++ is actually mirroring that of the problem domain. Nothing else gives us the level of abstraction that C++ does, while still offering convenient ways to specify low-level performance semantics. I think for a while Fortran was pulling ahead for large-scale numerical computing, but the mess of different options for parallelism (and also I think in our case a profileration of algorithm choices that made not just polymorphism but the explicit distinction between polymorphism and templates more important for code architecture) have brought C++ back into the limelight. I know that some competitors in our space have a Fortran codebase and they essentially had to hack together C++ Templates as part of their build process (i.e. pre-process a template file and generate multiple sources which are then compiled).
    - SamReidHughes 8y ago
      Looking at some C++ extension proposals, many are definitely a case of "devs gotta dev." Fortunately most of these don't have a chance in hell of making it in.
      - VHRanger 8y ago
        Yeah Stroustrup put his foot down this year on whacky proposals.
    - carlmr 8y ago
      I agree that in your case C or C++ is probably the way to go (I usually favor C, because while it affords less options for abstractions it also doesn't give so many possibilities to shoot yourself in the foot in unimaginable ways (still enough mind you)). Your parent poster is also right. Rust offers a lot of safety guarantees, a modern, well-designed language around it, package management, test and benchmarking integration, and extremely good type safety, while still mostly having zero cost abstractions for many things. If your goal is performance, control and safety, Rust is a much better choice than either C or C++. I'm still hopeful that it shall become the next big embedded language (mostly processor support missing here, but thanks to LLVM there's hope), especially since we haven't seen any other good attempt at GCless computing (no GC is pretty important for real-time systems). But I must admit that with C++ you can probably eke out a few % more performance. The thing is though that with Rust, for 99% of projects where performance and no-GC is important, will be fast enough, especially due to safe abstractions, often faster than C++. One example is if you have a lot of text processing to do. Often you can reuse a lot of the strings. In Rust you can safely handle this due to the borrow checker. Avoiding allocation of new strings is pretty much the biggest performance problem for most string processing. Rust gives you a lot of safety when it comes to multithreading as well. It's perfect for creating little servers and using all your processors for performance. These two together, and the lack of 2-3 day debugging sessions where you trace down that one tiny memory bug in C++, make Rust the biggest contender to replace C++. Of course if you only care about performance. C or C++ is probably still a slightly better choice, slightly.
carlmr 8y ago
It's already there, but it's really ugly and hard to read, would be my conclusion from this.
paulddraper 8y ago
"And if we are missing it, let's add it".
gHosts 8y ago
Yup. And while the rest of the world knew how to find a file size... how long was it before C++ cleaned that very very simple corner up? And if you look under the hood at the implementation of std::conditional.... I feel ill. The thing I like about Alexandrescu is he invented this meta programming stuff... super super super clever magic... ...and then backed away saying it shouldn't have to be so hard, we shouldn't need magic to program.

wyldfire 8y ago

Slides from Alexandrescu's referenced talk [1]. [1] http://erdani.com/MeetingC++2018Keynote.pdf http://erdani.com/MeetingC++2018Keynote.pdf

greesil 8y ago

I think I just got used to C++11. What is this dark magic?

felixguendling 8y ago
If you refer to `if constexpr`: There is no dark magic. Most of it is already possible with C++11 meta programming (i.e. with std::enable_if [0]). However, it's much more readable now (and it's more fun to write :D). I think we're on a good way that compile time programming will be more easily accessible. [0] https://en.cppreference.com/w/cpp/types/enable_if https://en.cppreference.com/w/cpp/types/enable_if
gpderetta 8y ago
Most of this stuff was possible in C++03. Newer standards only make it more convenient and (arguably) saner.

mattnewport 8y ago

I had similar thoughts when looking through the slides for Andrei's talk. A main argument in favor of static if over the mechanisms C++ offers to do the same things seems to be familiarity of if statements but having scope not be respected is such an unintuitive difference for anyone with experience in curly braces languages that it seems like a net loss in clarity to me. It looks more like using macros for conditional compilation. Overuse of if statements is generally something of a code smell and tends to make code harder to follow. To my taste the C++ way of doing things is generally preferable as a result even if more verbose. Given this is probably somewhat a matter of taste it is hard to justify changing C++ to match the D way IMO.

mark-r 8y ago

Why is it every time I see a new article about C++ features my eyes glaze over? Am I just getting old, or has C++ jumped the shark?

moron4hire 8y ago
I had a similar feeling. As a long-time C# programmer (how old is C#? That many years), I look at this and get really wide-eyed, "how is that at all a good idea?!" A lot of these features seem like ways to hack around the fact that C++ templates are not generics, they are literally templates for writing copies of classes. It seems like features like this are going to make code size explode. A lot of the examples also seem very smelly from an OOP perspective. We should one class be able to have different fields depending on template parameters? That seems like something one should do in a subclass.
- mattnewport 8y ago
  I'm very familiar with C++ and C# and overall I find I like C++ a lot better. There are a few nice convenience features of C# but knowing both languages I tend to find whenever they differ I feel like C++ made the better design choice. And C# going all in on OOP is a part of that. It's reasonably clear now that OOP was mostly a big mistake and a dead end. C++ is less infected by going all in on it as it has always been a multi paradigm language.
- adrianN 8y ago
  I'm not sure what you mean by generics if you think that C++ templates are not a kind of generics. Do you prefer that everything happens at runtime? Similarly, subclasses as opposed to templates carry a runtime cost. Virtual function calls are not free. Why pay that cost if you can deduce the right code from the types at compiletime? Besides, and this is probably a matter of opinion, I find code hard to follow that uses inheritance heavily.
  - Retra 8y ago
    By "generics", I presume they mean template parameters which are checked at declaration, not at use.

cjhanks 8y ago

I agree with this blog writer. Allowing typedefs to cross static if boundaries would be a major change to the way I read code. Unless there's a more substantive example demonstrating why using the existing metaprogramming is insufficient, its benefits are imo outweighed by its cost.

renox 8y ago
Well you already have to remember that 'if' introduces a scope but '#if' doesn't..
- cjhanks 8y ago
  I guess that's true. But I can't remember the last time I have used `#if` aside from header guards and optimization paths. So they do exist, but I almost never do this.

choeger 8y ago

Oh my. If only C++ would have used proper macros from the start...

adev_ 8y ago
There is nothing as "a proper macro". There is proper meta-programming support or a badly design language.
- choeger 8y ago
  A macro is a metal-level abstraction. So proper macros require proper metaprogramming support. And, I would argue, the other way around.
  - adev_ 8y ago
    And I would argue that a Macro is external language put on top of your language as a patch (hack), when your language is not expressive enough for genericity. Then yes, there is nothing as "proper" Macro. There is just an attempt to fix a limited language in the first place. And it is something that C++ arrived to solve ( not that badly ) currently.
gumby 8y ago
I discussed this once with Stroustrup. He mourned that the word "macro" had been "polluted" (his word, though I completely agreed) by the preprocessor and said "templates was the best we could do within the constraints of C". This was in the mid 90s and things are a lot better these days but still, I had better macro support writing Lisp in the 1970s.
- choeger 8y ago
  I am ready to believe that hygienic macros would have been difficult, but just using lisp macros should have been straightforward. Tbh, I think that templates were an adhoc, amateurish design decision.

JabavuAdams 8y ago

I used to be a C++ guy from the early 90s 'till about 2010. Every few months, I think "I should really learn the new C++ hotness", and then I read something like this. It's like a bunch of priests arguing about how best to fit a bunch of ugly angels on a pointless pin. It just feels so pointless. If you must use C++, just use another language to generate the C++. All this template mumbo jumbo. Who says your meta-programming language has to be the same as your target language? I used to spend some time looking for the perfect vector (as in linear-algebra) library. Templatized for vector dimension, data-type, blah blah blah. Dude, just use Python to generate it. Duplication doesn't violate DRY if the duplication is generated from a single higher-level source. Doing meta-programming in C++ is a really limited way of thinking.

nealabq 8y ago
> fit a bunch of ugly angels on a pointless pin. It just feels so pointless. A pointless pin would indeed be pointless.
mattnewport 8y ago
I don't think anyone on the C++ committee is proposing banning you from generating C++ code with Python. I also doubt anyone who's interested in C++ metaprogramming has failed to consider the possibility of doing codegen via other means. In light of these facts what seems rather pointless is your comment.
flukus 8y ago
> Who says your meta-programming language has to be the same as your target language? I'd lay blame at IDE's and they way the take over the build system along with intellisense. They don't play well with anything generated before the compile step. Even adding a build step is and alien concept to many, so we end up with the build step shoe horned into languages.