18 ms·

C++ at the End of 2022

114 points by signa11 4y ago

29athrowaway 4y ago
The most exciting news about C++ would not be added features, but removed features. That is what everyone in their heart is waiting for.
- jeffreyrogers 4y ago
  I'm glad C++ has added more features, it is a much nicer language than it used to be. string_view from C++17 is very convenient and just this past week I had to use std::latch from C++20.
  - witx 4y ago
    Yes, but the problem in my view is that for each of those small things we find useful they introduce tons of other features no one needs ...
    - jcelerier 4y ago
      Can you list some that are present in c++20?
    - usefulcat 4y ago
      s/no one/I/
- usefulcat 4y ago
  The only problem being that “everyone” can’t agree on which particular set of features should be removed. Breaking existing code is always going to be a tough sell, for hopefully obvious reasons.
  - Brybry 4y ago
    Would code need to be broken? I thought it was normal to deprecate features and then have the compiler throw a warning.
    - Jare 4y ago
      "Treat warnings as errors" is a standard best practice.
      - Gibbon1 4y ago
        Treat warnings as errors is terrible practice.
        still_grokking 4y ago
        It's the only sane thing to do. And everybody who doesn't do so really deserves the pain that results later on.
        rightbyte 4y ago
        What is the point of having warnings then.
        still_grokking 4y ago
        You can suppress them in the rare cases this is needed. Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched. Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore. But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
        Gibbon1 4y ago
        Yeah at best you can force can force people unfamiliar with the code to waste their time suppressing a dumb ass warning that means nothing. Or worse accidentally introduce a bug.
- FpUser 4y ago
  >"That is what everyone in their heart is waiting for." Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.
  - nine_k 4y ago
    Operator delete still exists. Dereferencing void * still exists. Access like a[i] is still unchecked. Etc. But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
    - jcelerier 4y ago
      > Dereferencing void * still exists. ... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o https://gcc.godbolt.org/z/hK6qb1z6o
- pjmlp 4y ago
  Even Go gets to add features.
- omoikane 4y ago
  One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to. I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
  - 29athrowaway 4y ago
    They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help. If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more. C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. If you are using ancient C++, compiler security updates are the least of your security concerns. If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
    - int_19h 4y ago
      > C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
      - still_grokking 4y ago
        > I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP. Sounds like pure joy.
        int_19h 4y ago
- jcelerier 4y ago
  no, i really want reflection and better code generation features for instance ; this would allow me to simplify and remove a lot of useless code. likewise, "deducing this" which made it into C++23 is likely going to allow me to remove at least a few hundred and hopefully a few thousand lines of the codebase I'm working on. And all this means less chances for bugs and more time actually writing features.
  - still_grokking 4y ago
    > i really want reflection and better code generation features for instance I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3: https://docs.scala-lang.org/scala3/reference/metaprogramming/index.html https://docs.scala-lang.org/scala3/reference/metaprogramming... With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
    - jcelerier 4y ago
      Most of what you sent under this link falls under the general idea of reflection, e.g. the quoted macros, and is fairly similar to the kind of things that are being proposed for c++. Of course all the reflection systems proposed for c++ are purely compile-time, no one even proposed runtime reflection I think
      - still_grokking 4y ago
        For most people "reflection" is a synonym to "runtime reflection". In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹. Where can I learn more about the C++ proposals to compare? --- ¹ https://dl.acm.org/doi/10.1145/3136000.3136005 https://dl.acm.org/doi/10.1145/3136000.3136005 ¹ https://dl.acm.org/doi/10.1145/3158101 https://dl.acm.org/doi/10.1145/3158101 And the recent work that underlines the solution included in Scala 3: ¹ https://se.informatik.uni-tuebingen.de/publications/stucki21multistage.pdf https://se.informatik.uni-tuebingen.de/publications/stucki21...
darknavi 4y ago
Maybe I am behind in the times but it was a little surprising to me to see MSVC have full C++20 support while GCC and Clang are still trying to get there.
- delta_p_delta_x 4y ago
  Has been the case for the past half decade, too. MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.
  - mmozeiko 4y ago
    Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.
- elabajaba 4y ago
  Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.
  - nindalf 4y ago
    Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?
    - pjmlp 4y ago
      Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?
pjmlp 4y ago
As noted on my Reddit comment, the low numbers on static analysis and sanitizers adoption are a bit sad, and shows the reality versus the typical comment that everyone is already using them.
- DrBazza 4y ago
  Low numbers in the 649 people that found and answered that survey, and are in the intersection of "people that answer online surveys" and "probably aren't beginners at C++". It would of course be helpful if all the many, many, many, build systems for C++ have 'integrating sanitizers' in their "hello world" tutorials, rather than buried in some arcane man page.
  - pjmlp 4y ago
    That is why it was so relevant that clang introduced static analysis as part of the compiler, instead of having to get hold of lint. However it isn't for it being there (VC++ can even do analysis per build), that people are rushing to adopt them after all these decades (lint was born in 1979). So the social aspect matters a lot, and we keep losing there.
    - DrBazza 4y ago
      Had I answered that survey, I would have added a 0.1% or so to the sanitizers. Everywhere I've worked (now) runs sanitizers over the build. > So the social aspect matters a lot, and we keep losing there. Unfortunately. For example, there's a "cmake" starter on github, that is everything including santizers, but it is, frankly, inaccessible to newbies that just want to learn C++ "from scratch". Compare that to... Rust. You create a new crate from the cli in one command, and then you never have to mess around with the build system. Or even java/kotlin... `gradle init`... and you're mostly done. C++? "Spends 15 minutes reading "build system X" docs...".
      - damidekronik 4y ago
        I wish it was only 15 minutes.
saboot 4y ago
ctrl+f "reflection" no results found. maybe next year ..
- pjmlp 4y ago
  With luck, maybe after C++26, if at all.
  - suby 4y ago
    There is something very wrong if they don't have reflection in 26. It is sorely needed.
    - pjmlp 4y ago
      What is wrong is having 200 plus ISO members with different mindsets in what to vote for. People often talk about Bjarne Stroustoup as if he was a BDFL, while in reality he only has one vote from those 200 plus. Welcome to standard body processes.
- sakesun 4y ago
  Try C++ Builder
- okamiueru 4y ago
  Maybe not relevant to your interests, but I found this very interesting on the topic https://www.youtube.com/watch?v=aJt2POa9oCM https://www.youtube.com/watch?v=aJt2POa9oCM A case of "brilliant coder wants to make game but don't know art well, so they create new complicated programming tasks instead", but, the brilliant coder part is still pretty relevant.
- still_grokking 4y ago
  What do they aim for? Runtime reflection? That's something that's indeed not very important. At least as long as you've got some form of "compile time reflection". But OK, C++ does not have either. (You could build something for sure, templates are Turing complete, but I'm not sure I would even like to see the result; could be very scary…)
joebaf 4y ago
is ChatGPT actually the most important thing that happens... not just for C++, but in terms of all programming languages? How will it affect programming?
- klodolph 4y ago
  I’ve seen ChatGPT spit out both correct and incorrect code. The idea that you’d rely more on tools is in a sense the Java approach. Java is somewhat more verbose than other languages, in practice, and you deal with the verbosity by making more use of code snippets / templates, autocompletion, etc. Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, and improving code generation (via ChatGPT or some successor) does nothing to solve the actual problems with using generated code. At the end of the day, somebody has to at least read the code and verify that it does what is requested. Maybe at some point, someone will hook a more formal front-end to ChatGPT or something similar, so you can write the interfaces and specs, and the AI will generate the implementation. That may take a while, however.
  - still_grokking 4y ago
    > Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, […] I think language researchers would strongly disagree. Something like that is likely the future of programming! For example: https://www.youtube.com/watch?v=X36ye-1x_HQ https://www.youtube.com/watch?v=X36ye-1x_HQ From the video description: > In Idris, types are a first class language construct, meaning that they can be manipulated and computed like any other language construct. It encourages a type-driven style of development, in which programmers give types first and use interactive editing tools to derive programs.
- McP 4y ago
  I tried using GPT to write code and it was very impressive but this cartoon cuts to the truth of it: https://www.reddit.com/r/ProgrammerHumor/comments/zdvpwb/how_openai_chatgpt_helps_software_development/ https://www.reddit.com/r/ProgrammerHumor/comments/zdvpwb/how...
roca 4y ago
I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon https://github.com/carbon-language/carbon-lang/blob/trunk/do...
- nindalf 4y ago
  The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...). The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.” The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google. That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright. This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang. Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...)
  - fxtentacle 4y ago
    My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.
college_physics 4y ago
Its a bit disappointing that the C++ community and stakeholders haven't found a way to address perceived shortcomings and (why not) reinvigorate and generate excitement about the ecosystem. The fact that people choose to embark on enormous investments to build alternatives from scratch (e.g Rust) might suggest that the cost calculus between maintaining compatibility with legacy code and future-proofing the language has now shifted decidedly against the former. C++ does not feel like the kind of beast that is destined to become the new COBOL. Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.
- int_19h 4y ago
  I very much doubt that existing large C++ codebases - which are plenty - are going to fully or largely migrate to Rust (or whatever) within the next two decades. Given that C++ originates in mid-80s, that would make it as old as COBOL was in 2000.
  - nindalf 4y ago
    This is similar to saying that no one would migrate to TypeScript because there are so many existing JavaScript codebases. The success of TypeScript and Kotlin suggest that one of the languages that hope to interoperate with C++ like Carbon could become more popular over time.
    - gpderetta 4y ago
      I suspect that the average liftime of a typical c++ and js codebase differ by one or two orders of magnitude.
      - nindalf 4y ago
        You’re assuming the codebase would need to be rewritten. It’s always possible that there might be a gradual transition within the same codebase. New features could be implemented in the new language while keeping everything else the same.
nindalf 4y ago
Just another request to stop citing Tiobe. This index is misleading and harmful. https://blog.nindalf.com/posts/stop-citing-tiobe/ https://blog.nindalf.com/posts/stop-citing-tiobe/
- still_grokking 4y ago
  Where's the petition? Need to sign it! Tiobe is outright nonsense. Citing it (besides jokes) is usually a sign that you can't trust the source that does so in the first place. Really everybody should know (at least for the last few years) that the Tiobe index is just completely made up nonsense.
lizardactivist 4y ago
I haven't kept up with C++ for over a decade, but the little glimpses I catch of it makes me think that though it has received good and useful stuff, it has also grown needlessly complex.
Raptor22 4y ago
Can someone explain the differences between Google and the C++ standards committee? I understand it has to do with breaking ABI, but what exactly does this imply? As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. In Python, the default CPython interpreter is the standard - if it's not in CPython, it's not standard Python. But in C++, there's like 3 different compilers, all of which implement different subsets of the latest C++ standards. IIRC, the latest standard that all compilers implement fully is C++ 14. I understand C++ is a broad and complicated language, and I actually have liked using it in the few times I've had the chance, but the compiler/standard situation seems like complete lunacy from where I stand.
- deng 4y ago
  > As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. Yes, that's because C++ is a formally standardized language, and Python and Swift are not. C++ is an ISO standard, and it is published in text form. You are free to create your own compiler, and if it works according to the rules written in the official standard, you may call it a standard-conforming compiler. There are of course other languages which are also officially standardized like this (does not have to be ISO), for instance Common Lisp, Scheme and of course Javascript (ECMA). If a language is defined by a reference implementation, then this is an informal way of standardizing your language, and if you want to create your own compiler/interpreter for such a language, you have to carefully evaluate what the reference implementation does. > I understand it has to do with breaking ABI, but what exactly does this imply? Very roughly, it means that you cannot link object code with the current ABI with object code that was generated by older compilers with the old ABI (well, it's usually worse: you can link just fine, but your program might or might not crash). This is not unprecedented in C++, we had this when switching from gcc4 to gcc5, it was definitely pretty painful and I'd rather not have this again.
- yeputons 4y ago
  Google is a company which uses C++ in a specific way. For example, they build most of their code from source with the same compiler and compilation settings, including external dependencies. They do not use exceptions, some parts of the standard library, some parts of the language. They also can upgrade their codebase in more-or-less atomic company-wide refactorings which also run most (if not all) tests for the affected code. The C++ standards committee is a body of people from different backgrounds, different companies and different needs from C++. Moreover, they kind of have to cater to everybody. There may be people programming microcontrollers, there may be game developers, there may be people supporting/porting decades-old software which uses old versions of Qt, there may be people wanting all the modern bells and whistles in C++, and there may be people using pre-compiled third-party libraries from a long gone vendor or vendor not willing to upgrade their compiler. These needs may contradict each other. ABI (Application Binary Interface) in C++ can be thought of as a `.pyc` file in Python. You don't expect _any_ compatibility of `.pyc` files between Python versions, so all libraries are distributed in source code in `.py`, and it's up to Python to process them into `.pyc` files as it wants. In C++ world, lots of libraries (including all OS libraries, actually) are distributed in a pre-compiled binary form only. The way your program interacts with the library is the ABI. If you upgrade your compiler, but the library does not, you can no longer use the library. One example is the memory layout of standard library types. E.g. a release version of `std::vector` (the standard dynamic array container) may only need three fields: a pointer to the allocated memory, maximal capacity of the vector, and its current size. A debug version may also include stuff like "where this vector was created". If one part of your program (or an external library) expects a vector to be 24 bytes and have such and such fields, and another part expects something else, Everyone Dies(tm). To make things worse, everything breaks silently: there are little to no checks for ABI compatibility, and reading a byte almost always works. As to why the standard is affected by this, even though "ABI" is not mentioned anywhere in the text: you cannot add/remove fields or virtual methods within the standard library in the next standard. If you do, the newer standard library _must_ become incompatible with all the pre-compiled code expecting the older version. (Almost) no way around it. A similar thing in Python would be if one has tried to use both Python 2 and Python in the same project simultaneously, in the same process. So if everyone starts building all their code and dependencies from the source code, there will be no ABI concerns anymore. I don't see it happening any time. > IIRC, the latest standard that all compilers implement fully is C++ 14. Not even than, garbage collection from C++11 was never implemented by any compiler: https://en.cppreference.com/w/cpp/compiler_support/11 https://en.cppreference.com/w/cpp/compiler_support/11 Not a big problem though, as it's never used by anyone. I've heard of people using non-standard garbage collection extensions instead, long before C++11. That's another thing with the standard and compilers: not everyone needs every feature, so some are given a priority depending on the compiler's users. And there are lots of existing solutions which probably won't be migrated to the standard.
raymond_goo 4y ago
Ctrl-F "networking", close tab...

114 points by signa11 4y ago

The most exciting news about C++ would not be added features, but removed features. That is what everyone in their heart is waiting for.

jeffreyrogers 4y ago
I'm glad C++ has added more features, it is a much nicer language than it used to be. string_view from C++17 is very convenient and just this past week I had to use std::latch from C++20.
- witx 4y ago
  Yes, but the problem in my view is that for each of those small things we find useful they introduce tons of other features no one needs ...
  - jcelerier 4y ago
    Can you list some that are present in c++20?
  - usefulcat 4y ago
    s/no one/I/
usefulcat 4y ago
The only problem being that “everyone” can’t agree on which particular set of features should be removed. Breaking existing code is always going to be a tough sell, for hopefully obvious reasons.
- Brybry 4y ago
  Would code need to be broken? I thought it was normal to deprecate features and then have the compiler throw a warning.
  - Jare 4y ago
    "Treat warnings as errors" is a standard best practice.
    - Gibbon1 4y ago
      Treat warnings as errors is terrible practice.
      - still_grokking 4y ago
        It's the only sane thing to do. And everybody who doesn't do so really deserves the pain that results later on.
        rightbyte 4y ago
        What is the point of having warnings then.
        still_grokking 4y ago
        You can suppress them in the rare cases this is needed. Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched. Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore. But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
        Gibbon1 4y ago
        Yeah at best you can force can force people unfamiliar with the code to waste their time suppressing a dumb ass warning that means nothing. Or worse accidentally introduce a bug.
FpUser 4y ago
>"That is what everyone in their heart is waiting for." Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.
- nine_k 4y ago
  Operator delete still exists. Dereferencing void * still exists. Access like a[i] is still unchecked. Etc. But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
  - jcelerier 4y ago
    > Dereferencing void * still exists. ... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o https://gcc.godbolt.org/z/hK6qb1z6o
pjmlp 4y ago
Even Go gets to add features.
omoikane 4y ago
One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to. I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
- 29athrowaway 4y ago
  They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help. If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more. C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. If you are using ancient C++, compiler security updates are the least of your security concerns. If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
  - int_19h 4y ago
    > C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
    - still_grokking 4y ago
      > I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP. Sounds like pure joy.
      - int_19h 4y ago
jcelerier 4y ago
no, i really want reflection and better code generation features for instance ; this would allow me to simplify and remove a lot of useless code. likewise, "deducing this" which made it into C++23 is likely going to allow me to remove at least a few hundred and hopefully a few thousand lines of the codebase I'm working on. And all this means less chances for bugs and more time actually writing features.
- still_grokking 4y ago
  > i really want reflection and better code generation features for instance I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3: https://docs.scala-lang.org/scala3/reference/metaprogramming/index.html https://docs.scala-lang.org/scala3/reference/metaprogramming... With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
  - jcelerier 4y ago
    Most of what you sent under this link falls under the general idea of reflection, e.g. the quoted macros, and is fairly similar to the kind of things that are being proposed for c++. Of course all the reflection systems proposed for c++ are purely compile-time, no one even proposed runtime reflection I think
    - still_grokking 4y ago
      For most people "reflection" is a synonym to "runtime reflection". In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹. Where can I learn more about the C++ proposals to compare? --- ¹ https://dl.acm.org/doi/10.1145/3136000.3136005 https://dl.acm.org/doi/10.1145/3136000.3136005 ¹ https://dl.acm.org/doi/10.1145/3158101 https://dl.acm.org/doi/10.1145/3158101 And the recent work that underlines the solution included in Scala 3: ¹ https://se.informatik.uni-tuebingen.de/publications/stucki21multistage.pdf https://se.informatik.uni-tuebingen.de/publications/stucki21...

darknavi 4y ago

Maybe I am behind in the times but it was a little surprising to me to see MSVC have full C++20 support while GCC and Clang are still trying to get there.

delta_p_delta_x 4y ago
Has been the case for the past half decade, too. MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.
- mmozeiko 4y ago
  Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.
elabajaba 4y ago
Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.
- nindalf 4y ago
  Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?
  - pjmlp 4y ago
    Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?

pjmlp 4y ago

As noted on my Reddit comment, the low numbers on static analysis and sanitizers adoption are a bit sad, and shows the reality versus the typical comment that everyone is already using them.

DrBazza 4y ago
Low numbers in the 649 people that found and answered that survey, and are in the intersection of "people that answer online surveys" and "probably aren't beginners at C++". It would of course be helpful if all the many, many, many, build systems for C++ have 'integrating sanitizers' in their "hello world" tutorials, rather than buried in some arcane man page.
- pjmlp 4y ago
  That is why it was so relevant that clang introduced static analysis as part of the compiler, instead of having to get hold of lint. However it isn't for it being there (VC++ can even do analysis per build), that people are rushing to adopt them after all these decades (lint was born in 1979). So the social aspect matters a lot, and we keep losing there.
  - DrBazza 4y ago
    Had I answered that survey, I would have added a 0.1% or so to the sanitizers. Everywhere I've worked (now) runs sanitizers over the build. > So the social aspect matters a lot, and we keep losing there. Unfortunately. For example, there's a "cmake" starter on github, that is everything including santizers, but it is, frankly, inaccessible to newbies that just want to learn C++ "from scratch". Compare that to... Rust. You create a new crate from the cli in one command, and then you never have to mess around with the build system. Or even java/kotlin... `gradle init`... and you're mostly done. C++? "Spends 15 minutes reading "build system X" docs...".
    - damidekronik 4y ago
      I wish it was only 15 minutes.

saboot 4y ago

ctrl+f "reflection" no results found. maybe next year ..

pjmlp 4y ago
With luck, maybe after C++26, if at all.
- suby 4y ago
  There is something very wrong if they don't have reflection in 26. It is sorely needed.
  - pjmlp 4y ago
    What is wrong is having 200 plus ISO members with different mindsets in what to vote for. People often talk about Bjarne Stroustoup as if he was a BDFL, while in reality he only has one vote from those 200 plus. Welcome to standard body processes.
sakesun 4y ago
Try C++ Builder
okamiueru 4y ago
Maybe not relevant to your interests, but I found this very interesting on the topic https://www.youtube.com/watch?v=aJt2POa9oCM https://www.youtube.com/watch?v=aJt2POa9oCM A case of "brilliant coder wants to make game but don't know art well, so they create new complicated programming tasks instead", but, the brilliant coder part is still pretty relevant.
still_grokking 4y ago
What do they aim for? Runtime reflection? That's something that's indeed not very important. At least as long as you've got some form of "compile time reflection". But OK, C++ does not have either. (You could build something for sure, templates are Turing complete, but I'm not sure I would even like to see the result; could be very scary…)

joebaf 4y ago

is ChatGPT actually the most important thing that happens... not just for C++, but in terms of all programming languages? How will it affect programming?

klodolph 4y ago
I’ve seen ChatGPT spit out both correct and incorrect code. The idea that you’d rely more on tools is in a sense the Java approach. Java is somewhat more verbose than other languages, in practice, and you deal with the verbosity by making more use of code snippets / templates, autocompletion, etc. Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, and improving code generation (via ChatGPT or some successor) does nothing to solve the actual problems with using generated code. At the end of the day, somebody has to at least read the code and verify that it does what is requested. Maybe at some point, someone will hook a more formal front-end to ChatGPT or something similar, so you can write the interfaces and specs, and the AI will generate the implementation. That may take a while, however.
- still_grokking 4y ago
  > Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, […] I think language researchers would strongly disagree. Something like that is likely the future of programming! For example: https://www.youtube.com/watch?v=X36ye-1x_HQ https://www.youtube.com/watch?v=X36ye-1x_HQ From the video description: > In Idris, types are a first class language construct, meaning that they can be manipulated and computed like any other language construct. It encourages a type-driven style of development, in which programmers give types first and use interactive editing tools to derive programs.
McP 4y ago
I tried using GPT to write code and it was very impressive but this cartoon cuts to the truth of it: https://www.reddit.com/r/ProgrammerHumor/comments/zdvpwb/how_openai_chatgpt_helps_software_development/ https://www.reddit.com/r/ProgrammerHumor/comments/zdvpwb/how...

roca 4y ago

I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon https://github.com/carbon-language/carbon-lang/blob/trunk/do...

nindalf 4y ago
The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...). The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.” The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google. That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright. This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang. Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...)
- fxtentacle 4y ago
  My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.

college_physics 4y ago

Its a bit disappointing that the C++ community and stakeholders haven't found a way to address perceived shortcomings and (why not) reinvigorate and generate excitement about the ecosystem. The fact that people choose to embark on enormous investments to build alternatives from scratch (e.g Rust) might suggest that the cost calculus between maintaining compatibility with legacy code and future-proofing the language has now shifted decidedly against the former. C++ does not feel like the kind of beast that is destined to become the new COBOL. Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.

int_19h 4y ago
I very much doubt that existing large C++ codebases - which are plenty - are going to fully or largely migrate to Rust (or whatever) within the next two decades. Given that C++ originates in mid-80s, that would make it as old as COBOL was in 2000.
- nindalf 4y ago
  This is similar to saying that no one would migrate to TypeScript because there are so many existing JavaScript codebases. The success of TypeScript and Kotlin suggest that one of the languages that hope to interoperate with C++ like Carbon could become more popular over time.
  - gpderetta 4y ago
    I suspect that the average liftime of a typical c++ and js codebase differ by one or two orders of magnitude.
    - nindalf 4y ago
      You’re assuming the codebase would need to be rewritten. It’s always possible that there might be a gradual transition within the same codebase. New features could be implemented in the new language while keeping everything else the same.

nindalf 4y ago

Just another request to stop citing Tiobe. This index is misleading and harmful. https://blog.nindalf.com/posts/stop-citing-tiobe/ https://blog.nindalf.com/posts/stop-citing-tiobe/

still_grokking 4y ago
Where's the petition? Need to sign it! Tiobe is outright nonsense. Citing it (besides jokes) is usually a sign that you can't trust the source that does so in the first place. Really everybody should know (at least for the last few years) that the Tiobe index is just completely made up nonsense.

lizardactivist 4y ago

I haven't kept up with C++ for over a decade, but the little glimpses I catch of it makes me think that though it has received good and useful stuff, it has also grown needlessly complex.

Raptor22 4y ago

Can someone explain the differences between Google and the C++ standards committee? I understand it has to do with breaking ABI, but what exactly does this imply? As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. In Python, the default CPython interpreter is the standard - if it's not in CPython, it's not standard Python. But in C++, there's like 3 different compilers, all of which implement different subsets of the latest C++ standards. IIRC, the latest standard that all compilers implement fully is C++ 14. I understand C++ is a broad and complicated language, and I actually have liked using it in the few times I've had the chance, but the compiler/standard situation seems like complete lunacy from where I stand.

deng 4y ago
> As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. Yes, that's because C++ is a formally standardized language, and Python and Swift are not. C++ is an ISO standard, and it is published in text form. You are free to create your own compiler, and if it works according to the rules written in the official standard, you may call it a standard-conforming compiler. There are of course other languages which are also officially standardized like this (does not have to be ISO), for instance Common Lisp, Scheme and of course Javascript (ECMA). If a language is defined by a reference implementation, then this is an informal way of standardizing your language, and if you want to create your own compiler/interpreter for such a language, you have to carefully evaluate what the reference implementation does. > I understand it has to do with breaking ABI, but what exactly does this imply? Very roughly, it means that you cannot link object code with the current ABI with object code that was generated by older compilers with the old ABI (well, it's usually worse: you can link just fine, but your program might or might not crash). This is not unprecedented in C++, we had this when switching from gcc4 to gcc5, it was definitely pretty painful and I'd rather not have this again.
yeputons 4y ago
Google is a company which uses C++ in a specific way. For example, they build most of their code from source with the same compiler and compilation settings, including external dependencies. They do not use exceptions, some parts of the standard library, some parts of the language. They also can upgrade their codebase in more-or-less atomic company-wide refactorings which also run most (if not all) tests for the affected code. The C++ standards committee is a body of people from different backgrounds, different companies and different needs from C++. Moreover, they kind of have to cater to everybody. There may be people programming microcontrollers, there may be game developers, there may be people supporting/porting decades-old software which uses old versions of Qt, there may be people wanting all the modern bells and whistles in C++, and there may be people using pre-compiled third-party libraries from a long gone vendor or vendor not willing to upgrade their compiler. These needs may contradict each other. ABI (Application Binary Interface) in C++ can be thought of as a `.pyc` file in Python. You don't expect _any_ compatibility of `.pyc` files between Python versions, so all libraries are distributed in source code in `.py`, and it's up to Python to process them into `.pyc` files as it wants. In C++ world, lots of libraries (including all OS libraries, actually) are distributed in a pre-compiled binary form only. The way your program interacts with the library is the ABI. If you upgrade your compiler, but the library does not, you can no longer use the library. One example is the memory layout of standard library types. E.g. a release version of `std::vector` (the standard dynamic array container) may only need three fields: a pointer to the allocated memory, maximal capacity of the vector, and its current size. A debug version may also include stuff like "where this vector was created". If one part of your program (or an external library) expects a vector to be 24 bytes and have such and such fields, and another part expects something else, Everyone Dies(tm). To make things worse, everything breaks silently: there are little to no checks for ABI compatibility, and reading a byte almost always works. As to why the standard is affected by this, even though "ABI" is not mentioned anywhere in the text: you cannot add/remove fields or virtual methods within the standard library in the next standard. If you do, the newer standard library _must_ become incompatible with all the pre-compiled code expecting the older version. (Almost) no way around it. A similar thing in Python would be if one has tried to use both Python 2 and Python in the same project simultaneously, in the same process. So if everyone starts building all their code and dependencies from the source code, there will be no ABI concerns anymore. I don't see it happening any time. > IIRC, the latest standard that all compilers implement fully is C++ 14. Not even than, garbage collection from C++11 was never implemented by any compiler: https://en.cppreference.com/w/cpp/compiler_support/11 https://en.cppreference.com/w/cpp/compiler_support/11 Not a big problem though, as it's never used by anyone. I've heard of people using non-standard garbage collection extensions instead, long before C++11. That's another thing with the standard and compilers: not everyone needs every feature, so some are given a priority depending on the compiler's users. And there are lots of existing solutions which probably won't be migrated to the standard.

raymond_goo 4y ago

Ctrl-F "networking", close tab...