HN

Comments (93)

• Menu

  suby
  I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified.Here's a quote from Bjarne,> So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much harder problem. This is part of the standard proposal. Do we vote against the standard because there is a feature we think is bad? Because I think this one is bad. And that is a much harder problem. People vote yes because they think: "Oh we are getting a lot of good things out of this.", and they are right. We are also getting a lot of complexity and a lot of bad things. And this proposal, in my opinion is bloated committee design and also incomplete.
• jcalvinowens
  The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost: int x [[indeterminate]]; std::cin >> x;
• LatencyKills
  This is awesome. I've was a dev on the C++ team at MS in the 90s and was sure that RTTI was the closest the language would ever get to having a true reflection system.
• Menu

  mohamedkoubaa
  Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption
• Menu

  dataflow
  > Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release.How far is Clang on reflection and contracts?
• chrisaycock
  std::execution is very interesting, but will be difficult to get started with, as cautioned by Sutter. This HPC Wire article demonstrates how to use standard C++ to benefit from asynchronously parallel computation on both CUDA and MPI:https://www.hpcwire.com/2022/12/05/new-c-sender-library-enab...Overlapping communication and computation has been a common technique for decades in high-performance computing to "hide latency", which leads to better scaling. Now standard C++ can be used to express parallel algorithms without tying to a specific scheduler.
• AyanamiKaine
  I am actually excited for post and pre conditions. I think they are an underused feature in most languages.
• einpoklum
  If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things:1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done).2. Uniform Function Call Syntax! That is, make the syntax `obj.f(arg)` mean simply `f(obj, arg)` . That would make my life much easier, both as a user of classes and as their author. In my library authoring work particularly. And while we're at it, let us us a class' name as a namespace for static methods, so that Obj::f the static method is simply the method f in namespace Obj.3. Get compiler makers to have an ABI break, so that we can do things like passing wrapped values in registers rather than going through memory. See: https://stackoverflow.com/q/58339165/15930774. Get rid of the current allocators in the standard library, which are type-specific (ridiculous) and return pointers rather than regions of memory. And speaking of memory regions (i.e. with address and size but no element type) - that should be standardized too.
• Menu

  affenape
  Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.
• levodelellis
  Great. C++20 has been my favorite and I was wasn't sure what the standards says since it's been a while. I'll be reading the C++26 standard soon
• Menu

  Tenobrus
  "Japanese soldier who kept fighting 29 years after World War 2"
• Menu

  porise
  I don't care until they stop pretending Unicode doesn't exist.
• Menu

  delduca
  Sadly, transparent hash strings for unordered_map are out.
• Menu

  VerifiedReports
  As long as programmers still have to deal with header files, all of this is lipstick on a pig.
• Menu

  FpUser
  I am curious what is their strategy to get language to the stage where the US government will make it cosher for new projects
• Menu

  rustyhancock
  I look forwards to getting to make use of this in 2040!Proper reflection is exciting.
• Menu

  ill_ion
  Contracts feel like the right direction but the wrong execution timeline. The Ada/SPARK model shows how powerful contracts become when they feed into static verification — but that took decades of iteration on a language with far cleaner semantics. Bolting that onto C++ where UB is load-bearing infrastructure is a different beast entirely. The real risk isn't complexity for complexity's sake — it's that a "minimum viable" contracts spec gets locked in, and then the things that would actually make it useful for proof assistants become impossible to retrofit because they'd break the v1 semantics. Bjarne's concern about "incomplete" is more worrying to me than "bloated."
• Menu

  the__alchemist
  Seeing that pic at the top of the article, and reflecting on my own experiences with rust: It is wild just how male-centric systems programming languages are. I'm from a career backround that's traditionally male-dominated (military aviation), but the balance is far more skewed among C, C++ and Rust developers.