6 ms·

Right now my biggest things I like from C++20 are: - Concepts (Now I can use static polymorphism without all those SFINAE template hacks) - Designated Initial

Right now my biggest things I like from C++20 are: - Concepts (Now I can use static polymorphism without all those SFINAE template hacks) - Designated Initializers (Finally!!! Using POD structs became way more convenient now) - Coroutines (Would be pretty nice for writing games / interactive applications) The things I don't have any interest in (but don't care if it's in or not) - Ranges (Too much complexity for something you could do with plain old for/if loops...) The things I'm worried about: - Modules (Theoretically really good, but in practice the whole thing is starting to become a mess, especially when it's interacting with the preprocessor and external libraries, and when trying to preserve backward compatibility.)

jokoon 7y ago
I have hope for modules because they can improve build times. Not exactly sure they would improve build time but if it's true, it would be a massive improvement.
- Renana 7y ago
  Have you tried using IncrediBuild. It's a dedicated solution to reduce C++ build times. If you're working on Windows, you can use it free (sharing the link to download): https://www.incredibuild.com/ibonlinestore/register#/regWindows?utm_source=hackernews&utm_medium=question&utm_campaign=answer&utm_content=download https://www.incredibuild.com/ibonlinestore/register#/regWind...
- saurik 7y ago
  Meanwhile, I am deeply concerned about modules, as it seems like the kind of feature that is going to massively harm build times by making it much more difficult to do truly independent distributed builds (which right now is pretty easy with C/C++ due to its separate compilation and extremely explicit inter-file dependencies).
  - vips7L 7y ago
    Wasn't the point of modules to decrease compilation/build times?
    - saurik 7y ago
      Some claim this, but I haven't seen it play out this way yet in what I have seen for modules; it could be that people are hyper-optimizing for serial performance when the future (and present!) is parallel? If so, :(. This article is possibly out of date--or maybe was wrong to begin with--but it shows how the modules concept from earlier this year simply broke parallel build efforts by enforcing a ton of serial dependencies. https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://vector-of-bool.github.io/2019/01/27/modules-doa.html
      - BubRoss 7y ago
        I have also seen this. My guess is that it highlights more that there are way too many dependencies in the libraries being used and that those dependencies aren't organized well.
  - naasking 7y ago
    Modules make separate compilation possible. C++ does not really have separate compilation right now.
    - saurik 7y ago
      I do not understand this comment, as I have done separate compilation every day with C++ for over two two decades: the model inherently only allows this, as every translation unit absolutely must be compiled separately and then linked... you don't even have a choice in the matter. I have also used both off-the-shelf and custom distributed build systems (most recently, I have deployed one which does insanely-parallel builds of a C++2a codebase using AWS Lambda), which pair extremely well with the explicit file-oriented dependencies that can be reported by each translation unit and used to determine which parts of the build are now stale given changes to the filesystem. I have never seen languages with module systems support even basic separate compilation, and it terrifies me; meanwhile, the flags I have seen being added to clang for attempting to preserve separate compilation behavior with the modules spec doesn't leave me feeling good about the endeavor. It could be my fears are unjustified, but it is extremely strange and somewhat annoying that the advocates for it don't ever seem to appreciate the state of the art for the status quo.
      - naasking 7y ago
        > I do not understand this comment, as I have done separate compilation every day with C++ for over two two decades: the model inherently only allows this, as every translation unit absolutely must be compiled separately and then linked... you don't even have a choice in the matter. Except if your headers include macros or templates, which must be evaluated every time. This is not separate compilation. What C/C++ developers have been doing for 20 years is jumping through hoops to incrementally reuse previously compiled results because C/C++ violate basic modularity principles [1]. They call it "separate compilation", but it's a pale shadow of true separate compilation. Proper modules would enforce abstraction boundaries so true separate compilation becomes possible. I can't speak to the specific C++ proposal here, but enabling separate compilation is exactly what modules are for. [1] http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
  - zelly 7y ago
    You can still do distributed builds with modules. You can't have cyclic dependencies anymore though. Your code has to be structured into logical modules that are meant to be built in parallel. It's not going to be free. You could have replicated modules with the old preprocessor style, but this way it is formalized and enforced by the compiler.
mangix 7y ago
OTOH ranges usually get compiled to faster and more efficient code. Smaller too.
- jcelerier 7y ago
  > OTOH ranges usually get compiled to faster and more efficient code. Smaller too. than raw loops ? do you have an example ?
  - mangix 7y ago
    Not particularly. However I do develop on OpenWrt where size is important. On some C++ projects, when I convert the for loops to range based ones using clang-tidy's modernize-loop-convert, I usually get a reduction in compiled size (compiling with -Os of course).
    - in3d 7y ago
      If think the parent was talking more about C++20 ranges based on the range-v3 library, not about the for loop ranges.
      - jcelerier 7y ago
        that is indeed the case.
ephaeton 7y ago
Designated Initializers done awkwardly a.k.a. "the C++ way" // Point2D point2d {.y = 2, .x = 1}; // (1) error Oh my. The C++ committee keeps their flight altitude rivaling moles and worms. This is another brittle feature, just like the initializer lists that have to mirror the declaration order. In what world is this a better option than allowing any order? Can't compiler implementors be bothered or what is the rationale?? C does this better.
- hohenheim 7y ago
  I think you are confused about the intention. If you want order independent initialization you could just as well use the old initializer list. The idea here is that you DON'T want to accidentally initialize x with y.
  - ephaeton 7y ago
    I don't think I am confused. The point is that, logically, either you do not tag something with names, and then, naturally, the order decides. Or, you tag something with names, and then, given you named things, there ought to be no order. Not so with the C++ initializers. An initializer list in a constructor should mirror the declaration order, or you won't go warning free. Every time you'd touch the internals of your class, you'd need to touch every constructor that uses an initializer list. Same with the struct initializers now. You are having this: struct A { int a, b, c}; you need to do this: A a = { .a = 1, .c = 3}; but you can't do this: A a = { .c = 3, .a = 1}; because... well, because C++. There is no reason to disallow the second form except for .. what exactly? What is the reasoning of the C++ committee to not be able to mirror what one can do in C (where, aside of the missing typedef or "struct" in front of A, both forms are valid)? Just as you're saying, the C++ committee seems to be confused about order-dependent and named initializations, and for some love-of-bean-counting insist that named initialization needs to respect order _as well_.
    - gpderetta 7y ago
      There is of course a reason which is well documented in the papers. Constructors, and initialization expressions can have side effects in C++. An invariant of the language is that member constructors are always invoked in declaration order, so if you were to swap the initializers around, the compiler would still have to initialize them in the original order, which would be surprising. Which does not means that it couldn't be done, in fact constructor initializer lists have the same issue and you are allowed to list them in any order but this is considered a language mistake and most compilers warn about out of order initializer. This mirror the arbitrary evaluation order of function parameters which is also considered a mistake. In the end there was no consensus to allowing an arbitrary order, but in the future that can be relaxed without breaking any code if a consensus is reached, while the reverse could not be done. As usual it is always compromises. Anyway, at last for me, initializers are more about writing more explicit code and be more robust in the face of changes.

jokoon 7y ago

I have hope for modules because they can improve build times. Not exactly sure they would improve build time but if it's true, it would be a massive improvement.

Renana 7y ago
Have you tried using IncrediBuild. It's a dedicated solution to reduce C++ build times. If you're working on Windows, you can use it free (sharing the link to download): https://www.incredibuild.com/ibonlinestore/register#/regWindows?utm_source=hackernews&utm_medium=question&utm_campaign=answer&utm_content=download https://www.incredibuild.com/ibonlinestore/register#/regWind...
saurik 7y ago
Meanwhile, I am deeply concerned about modules, as it seems like the kind of feature that is going to massively harm build times by making it much more difficult to do truly independent distributed builds (which right now is pretty easy with C/C++ due to its separate compilation and extremely explicit inter-file dependencies).
- vips7L 7y ago
  Wasn't the point of modules to decrease compilation/build times?
  - saurik 7y ago
    Some claim this, but I haven't seen it play out this way yet in what I have seen for modules; it could be that people are hyper-optimizing for serial performance when the future (and present!) is parallel? If so, :(. This article is possibly out of date--or maybe was wrong to begin with--but it shows how the modules concept from earlier this year simply broke parallel build efforts by enforcing a ton of serial dependencies. https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://vector-of-bool.github.io/2019/01/27/modules-doa.html
    - BubRoss 7y ago
      I have also seen this. My guess is that it highlights more that there are way too many dependencies in the libraries being used and that those dependencies aren't organized well.
- naasking 7y ago
  Modules make separate compilation possible. C++ does not really have separate compilation right now.
  - saurik 7y ago
    I do not understand this comment, as I have done separate compilation every day with C++ for over two two decades: the model inherently only allows this, as every translation unit absolutely must be compiled separately and then linked... you don't even have a choice in the matter. I have also used both off-the-shelf and custom distributed build systems (most recently, I have deployed one which does insanely-parallel builds of a C++2a codebase using AWS Lambda), which pair extremely well with the explicit file-oriented dependencies that can be reported by each translation unit and used to determine which parts of the build are now stale given changes to the filesystem. I have never seen languages with module systems support even basic separate compilation, and it terrifies me; meanwhile, the flags I have seen being added to clang for attempting to preserve separate compilation behavior with the modules spec doesn't leave me feeling good about the endeavor. It could be my fears are unjustified, but it is extremely strange and somewhat annoying that the advocates for it don't ever seem to appreciate the state of the art for the status quo.
    - naasking 7y ago
      > I do not understand this comment, as I have done separate compilation every day with C++ for over two two decades: the model inherently only allows this, as every translation unit absolutely must be compiled separately and then linked... you don't even have a choice in the matter. Except if your headers include macros or templates, which must be evaluated every time. This is not separate compilation. What C/C++ developers have been doing for 20 years is jumping through hoops to incrementally reuse previously compiled results because C/C++ violate basic modularity principles [1]. They call it "separate compilation", but it's a pale shadow of true separate compilation. Proper modules would enforce abstraction boundaries so true separate compilation becomes possible. I can't speak to the specific C++ proposal here, but enabling separate compilation is exactly what modules are for. [1] http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
- zelly 7y ago
  You can still do distributed builds with modules. You can't have cyclic dependencies anymore though. Your code has to be structured into logical modules that are meant to be built in parallel. It's not going to be free. You could have replicated modules with the old preprocessor style, but this way it is formalized and enforced by the compiler.

mangix 7y ago

OTOH ranges usually get compiled to faster and more efficient code. Smaller too.

jcelerier 7y ago
> OTOH ranges usually get compiled to faster and more efficient code. Smaller too. than raw loops ? do you have an example ?
- mangix 7y ago
  Not particularly. However I do develop on OpenWrt where size is important. On some C++ projects, when I convert the for loops to range based ones using clang-tidy's modernize-loop-convert, I usually get a reduction in compiled size (compiling with -Os of course).
  - in3d 7y ago
    If think the parent was talking more about C++20 ranges based on the range-v3 library, not about the for loop ranges.
    - jcelerier 7y ago
      that is indeed the case.

ephaeton 7y ago

Designated Initializers done awkwardly a.k.a. "the C++ way" // Point2D point2d {.y = 2, .x = 1}; // (1) error Oh my. The C++ committee keeps their flight altitude rivaling moles and worms. This is another brittle feature, just like the initializer lists that have to mirror the declaration order. In what world is this a better option than allowing any order? Can't compiler implementors be bothered or what is the rationale?? C does this better.

hohenheim 7y ago
I think you are confused about the intention. If you want order independent initialization you could just as well use the old initializer list. The idea here is that you DON'T want to accidentally initialize x with y.
- ephaeton 7y ago
  I don't think I am confused. The point is that, logically, either you do not tag something with names, and then, naturally, the order decides. Or, you tag something with names, and then, given you named things, there ought to be no order. Not so with the C++ initializers. An initializer list in a constructor should mirror the declaration order, or you won't go warning free. Every time you'd touch the internals of your class, you'd need to touch every constructor that uses an initializer list. Same with the struct initializers now. You are having this: struct A { int a, b, c}; you need to do this: A a = { .a = 1, .c = 3}; but you can't do this: A a = { .c = 3, .a = 1}; because... well, because C++. There is no reason to disallow the second form except for .. what exactly? What is the reasoning of the C++ committee to not be able to mirror what one can do in C (where, aside of the missing typedef or "struct" in front of A, both forms are valid)? Just as you're saying, the C++ committee seems to be confused about order-dependent and named initializations, and for some love-of-bean-counting insist that named initialization needs to respect order _as well_.
  - gpderetta 7y ago
    There is of course a reason which is well documented in the papers. Constructors, and initialization expressions can have side effects in C++. An invariant of the language is that member constructors are always invoked in declaration order, so if you were to swap the initializers around, the compiler would still have to initialize them in the original order, which would be surprising. Which does not means that it couldn't be done, in fact constructor initializer lists have the same issue and you are allowed to list them in any order but this is considered a language mistake and most compilers warn about out of order initializer. This mirror the arbitrary evaluation order of function parameters which is also considered a mistake. In the end there was no consensus to allowing an arbitrary order, but in the future that can be relaxed without breaking any code if a consensus is reached, while the reverse could not be done. As usual it is always compromises. Anyway, at last for me, initializers are more about writing more explicit code and be more robust in the face of changes.