Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

Post reply on HN
Print view View original

71–80 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#71

Post by zrm »

mgaunard wrote: post #25
luka598 wrote: post #13

Earlier quoted context omitted.

Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course…

> C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous.

It seems to me the "convenient" options are the dangerous ones.

The traditional method is for third party code to have a stable API. Newer versions add functions or fix bugs but existing functions continue to work as before. API mistakes get deprecated and alternatives offered but newly-deprecated functions remain available for 10+ years. With the result that you can link all applications against any sufficiently recent version of the library, e.g. the latest stable release, which can then be installed via the system package manager and have a manageable maintenance burden because only one version needs to be maintained.

Language package managers have a tendency to facilitate breaking changes. You "don't have to worry" about removing functions without deprecating them because anyone can just pull in the older version of the code. Except the older version is no longer maintained.

Then you're using a version of the code from a few years ago because you didn't need any of the newer features and it hadn't had any problems, until it picks up a CVE. Suddenly you have vulnerable code running in production but fixing it isn't just a matter of "apt upgrade" because no one else is going to patch the version only you were using, and the current version has several breaking changes so you can't switch to it until you integrate them into your code.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#73

Post by seertaak »

suby wrote: post #11

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…

Can you share what aspects of the design you (and Stroustroup) aren't happy with? Stroustroup has a tendency of being proven right, with 1-3 decade lag.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#74

Post by cedws »

Tenobrus wrote: post #72

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

I watched a talk from Bjarne Stroustrup at CppCon about safety and it was pretty second hand embarrassing watching him try to pretend C++ has always been safe and safety mattered all along to them before Rust came along.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#75

Post by dislikedopinion »

stackghost wrote: post #58
dislikedopinion wrote: post #24

Earlier quoted context omitted.

Might be the case that Ada folks successfully got a bad version of contracts not amenable for compile-time checking into C++, to undermine the competition. Time might tell.

I strongly doubt that C++ is what's standing in the way of Ada being popular.

Ada used to be mandated in the US defense industry, but lots of developers and companies preferred C++ and other languages, and for a variety of reasons, the mandate ended, and Ada faded from the spotlight.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#76

Post by jandrewrogers »

FpUser wrote: post #64

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

No such strategy is necessary. That discourse was about not using C++ for applications where Java would work just as well.

The US government still uses C++ widely for new projects. For some types of applications it is actually the language of choice and will remain so for the foreseeable future.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#77

Post by dislikedopinion »

steveklabnik wrote: post #55
dislikedopinion wrote: post #24

Earlier quoted context omitted.

Might be the case that Ada folks successfully got a bad version of contracts not amenable for compile-time checking into C++, to undermine the competition. Time might tell.

This is some pretty major conspiracy thinking, and would need some serious evidence. Do you have any?

[flagged]

Re: C++26 is done: ISO C++ standards meeting Trip Report

#78

Post by devnullbrain »

suby wrote: post #11

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…

Source of quote:

https://youtu.be/tzXu5KZGMJk?t=3160

Re: C++26 is done: ISO C++ standards meeting Trip Report

#79

Post by jjmarr »

mgaunard wrote: post #25
luka598 wrote: post #13

Earlier quoted context omitted.

Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course…

"Stable ABI" is a joke in C++ because you can't keep ABI and change the implementation of a templated function, which blocks improvements to the standard library.

In C, ABI = API because the declaration of a function contains the name and arguments, which is all the info needed to use it. You can swap out the definition without affecting callers.

That's why Rust allows a stable C-style ABI; the definition of a function declared in C doesn't have to be in C!

But in a C++-style templated function, the caller needs access to the definition to do template substitution. If you change the definition, you need to recompile calling code i.e. ABI breakage.

If you don't recompile calling code and link with other libraries that are using the new definition, you'll violate the one-definition rule (ODR).

This is bad because duplicate template functions are pruned at link-time for size reasons. So it's a mystery as to what definition you'll get. Your code will break in mysterious ways.

This means the C++ committee can never change the implementation of a standardized templated class or function. The only time they did was a minor optimization to std::string in 2011 and it was such a catastrophe they never did it again.

That is why Rust will not support stable ABIs for any of its features relying on generic types. It is impossible to keep the ABI stable and optimize an implementation.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#80

Post by steveklabnik »

dislikedopinion wrote: post #77
steveklabnik wrote: post #55

Earlier quoted context omitted.

This is some pretty major conspiracy thinking, and would need some serious evidence. Do you have any?

[flagged]

Okay, on one hand, I'm very curious, but on the other hand, not really on topic for this forum. So I'll just leave a "wut".
Post reply on HN