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

121–130 of 437 posts

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

#121

Post by kajaktum »

addaon wrote: post #17
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…

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration.

C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility.

It does not matter what version of C++ you are using, you are still using C with classes.

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

#122

Post by mgaunard »

NetMageSCW wrote: post #29
mgaunard wrote: post #25

Earlier quoted context omitted.

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…

I would suggest importing binaries and metadata is going to be faster than compiling all the source for that.

You'd be wrong. If the build system has full knowledge on how to build the whole thing, it can do a much better job. Caching the outputs of the build is trivial.

If you import some ready made binaries, you have no way to guarantee they are compatible with the rest of your build or contain the features you need. If anything needs updating and you actually bother to do it for correctness (most would just hope it's compatible) your only option is usually to rebuild the whole thing, even if your usage only needed one file.

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

#123

Post by mgaunard »

maccard wrote: post #115
mgaunard wrote: post #111

Earlier quoted context omitted.

Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again. You should also avoid libraries, as they reduce granularity and needlessly complexify the logic. I'd also argue you shouldn't have any kind of declaration of dependencies and simply deduce them transparently based on what the code incl…

The problem is doing this requires a team to support it that is realistically as large as your average product team. I know Bazel is the solution here but as someone who has used C++, modified build systems and maintained CI for teams for years, I have never gotten it to work for anything more than a toy project.

I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days.

Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based.

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

#124

Post by mgaunard »

stackghost wrote: post #113
mgaunard wrote: post #111

Earlier quoted context omitted.

Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again. You should also avoid libraries, as they reduce granularity and needlessly complexify the logic. I'd also argue you shouldn't have any kind of declaration of dependencies and simply deduce them transparently based on what the code incl…

>Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again. Which tool do you use for content-addressable storage in your builds? >You should also avoid libraries, as they reduce granularity and needlessly complexify the logic. This isn't always feasible though. What's the best practice when o…

You can use S3 or equivalent; a normal filesystem (networked or not) also works well.

You hash all the inputs that go into building foo.cpp, and then that gives you /objs/.o. If it exists, you use it; if not, you build it first. Then if any other .cpp file ever includes foo.hpp (directly or indirectly), you mark that it needs to link /objs/.o.

You expand the link requirements transitively, and you have a build system. 200 lines of code. Your code is self-describing and you never need to write any build logic again, and your build system is reliable, strictly builds only what it needs while sharing artifacts across the team, and never leads to ODR.

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

#125

Post by mgaunard »

jjmarr wrote: post #70
lenkite wrote: post #35

Earlier quoted context omitted.

Speedy convenience beats absolute correctness anyday. Humans are not immortal and have finite amount of time for life and work. If convenience didn't matter, we would all still be coding in assembly or toggling hardware switches.

C++ builds are extremely slow because they are not correct. I'm doing a migration of a large codebase from local builds to remote execution and I constantly have bugs with mystery shared library dependencies implicitly pulled from the environment. This is extremely tricky because if you run an executable without its shared library, you get "file not found" with no explanation. Even AI doesn't understand this error.

The dynamic linker can clearly tell you where it looks for files and in which order, and where it finds them if it does.

You can also very easily harden this if you somehow don't want to capture libraries from outside certain paths.

You can even build the compiler in such a way that every binary it produces has a built-in RPATH if you want to force certain locations.

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

#126

Post by kccqzy »

leni536 wrote: post #90
usrnm wrote: post #56

Earlier quoted context omitted.

What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode

Too much unicode in standard C++? Where?

Things like char32_t, std::u32string for storing UTF-32 characters.

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

#127

Post by kevin_thibedeau »

spacechild1 wrote: post #69
quotemstr wrote: post #54

Earlier quoted context omitted.

But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.

Pre- and postconditions are actually part of the function signature, i.e. they are visible to the caller. For example, static analyzers could detect contract violations just by looking at the callsite, without needing access to the actual function implementation. The pre- and postconditions can also be shown in IDE tooltips. You can't do this with your own contracts implementation. Finally, it certainly helps to have…

Is a pointer parameter an input, output, or both?

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

#128

Post by jandrewrogers »

FpUser wrote: post #89
jandrewrogers wrote: post #76

Earlier quoted context omitted.

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.

>"For some types of applications it is actually the language of choice..." Can you give an example please? And how does it correspond to government ONCD report and other government docs "recommending" "safe" languages like: Rust (noted for its ability to prevent memory-unsafe code), Go, Java, Swift, C#, Ruby, Ada Among other things I design and implement high performance C++ backends. for some I got SOCS2 Type II cer…

It is the high-performance/high-scale data processing and storage engines for data-intensive applications, some of which are used in high-assurance environments. These are used outside of defense/intel (the data models are generic) but defense/intel tends to set the development standards for government since theirs are the strictest and most rigorous.

An increasingly common requirement is the ability to robustly reject adversarial workloads in addition to being statically correct. Combined with the high-performance/high-scale efficiency requirements, this dictates what the software architecture can look like.

There are a few practical reasons Rust is not currently considered an ideal fit for this type of development. The required architecture largely disables Rust's memory-safety advantages. Modern C++ has significantly better features and capabilities under these constraints, yielding a smaller, more maintainable code base. People worry about supply chain attacks but I don't think that is a major factor here.

Less obvious, C++ has strong compile-time metaprogramming and execution features that can be used to extensively automate verification of code properties with minimal effort. This allows you to trivially verify many correctness properties of the code that Rust cannot. It ends up being a comparison of unsafe Rust versus verification maximalist C++20, which tilts the safety/reliability aspects pretty hard toward C++. Code designed to this standard of reliability has extremely low defect rates regardless of language but it is much easier in some languages than others. I even shipped Python once.

A lot of casual C++ code doesn't bother with this level of verification, though they really should. It has been possible for years now. More casual applications also have more exposure to memory safety issues but those mostly use Java in my experience, at least in government.

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

#129

Post by jjmarr »

mgaunard wrote: post #125
jjmarr wrote: post #70

Earlier quoted context omitted.

C++ builds are extremely slow because they are not correct. I'm doing a migration of a large codebase from local builds to remote execution and I constantly have bugs with mystery shared library dependencies implicitly pulled from the environment. This is extremely tricky because if you run an executable without its shared library, you get "file not found" with no explanation. Even AI doesn't understand this error.

The dynamic linker can clearly tell you where it looks for files and in which order, and where it finds them if it does. You can also very easily harden this if you somehow don't want to capture libraries from outside certain paths. You can even build the compiler in such a way that every binary it produces has a built-in RPATH if you want to force certain locations.

That is what I'm doing so I can get distributed builds working. It sucks and has taken me days of work.

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

#130

Post by daemin »

zarzavat wrote: post #7
mohamedkoubaa wrote: post #2

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

The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.

I may be in the minority but I like that C++ has multiple package managers, as you can use whichever one best fits your use case, or none at all if your code is simple enough.

It's the same with compilers, there's not one single implementation which is the compiler, and the ecosystem of compilers makes things more interesting.

Post reply on HN