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

111–120 of 437 posts

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

#111

Post by mgaunard »

stackghost wrote: post #28
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…

>There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?

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 includes, with some logic to map header to implementation files.

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

#112

Post by cedws »

einpoklum wrote: post #95
cedws wrote: post #74

Earlier quoted context omitted.

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.

Well, there has been a long campaign against manual memory management - well before Rust was a thing. And along with that, a push for less use of raw pointers, less index loops etc. - all measures which, when adopted, reduce memory safety hazards significantly. Following the Core Guideliness also helps, as does using span's. Compiler warnings has improved, as has static analysis, also in a long process preceding Rust…

>Following the Core Guideliness also helps

Yes, this what Stroustrup said and it makes me laugh. IIRC he phrased with a more of a 'we had safety before Rust' attitude. It also misses the point, safety shouldn't be opt-in or require memorising a rulebook. If safety is that easy in C++ why is everyone still sticking their hand in the shredder?

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

#113

Post by stackghost »

mgaunard wrote: post #111
stackghost wrote: post #28

Earlier quoted context omitted.

>There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?

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 one cannot avoid a library?

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

#114

Post by rr808 »

I switched from C++ to Java/Python 20 years ago. I never really fit in, I just dont understand when people talk about the complicated frameworks to avoid multithreading/mutexes etc when basic C++ multi threading is much simpler than rxjava or async/await or whatever is flavor of the month.

But C++ projects are usually really boring. I want to go back but glad I left. Has anyone found a place where C++ style programming is in fashion but isn't quite C++? I hope that makes sense.

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

#115

Post by maccard »

mgaunard wrote: post #111
stackghost wrote: post #28

Earlier quoted context omitted.

>There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?

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.

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

#116

Post by zozbot234 »

tialaramex wrote: post #53
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…

It's not true that Rust rejects "the notion of a stable ABI". Rust rejects the C++ solution of freeze everything and hope because it's a disaster, it's less stable than some customers hoped and yet it's frozen in practice so it disappoints others. Rust says an ABI should be a promise by a developer, the way its existing C ABI is, that you can explicitly make or not make. Rust is interested in having a properly though…

> It'd be nice to have say, ABI for slices for example.

The de-facto ABI for slices involves passing/storing pointer and length separately and rebuilding the slice locally. It's hard to do better than that other than by somehow standardizing a "slice" binary representation across C and C-like languages. And then you'll still have to deal with existing legacy code that doesn't agree with that strict representation.

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

#117

Post by tialaramex »

seertaak wrote: post #73
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.

Certainly we can say that Bjarne will insist he was right decades later. We can't necessarily guess - at the time - what it is he will have "always" believed decades later though.

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

#118

Post by jjmarr »

sgt wrote: post #68
jjmarr wrote: post #40

Earlier quoted context omitted.

You don't on new projects. CMake + ninja has support for modules on gcc, clang, and MSVC. This should be your default stack on any small-to-medium sized C++ project. Bazel, the default pick for very large codebases, also has support for C++20 modules.

How about using Zig to build C++ projects?

I haven't used it.

That being said, while it looks better than CMake, for anything professional I need remote execution support to deviate from the industry standard. Zig doesn't have that.

This is because large C++ projects reach a point where they cannot be compiled locally if they use the full language. e.g. Multi-hour Chromium builds.

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

#119

Post by mgaunard »

uecker wrote: post #81
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…

"That makes everything slow, inefficient, and widely dangerous." There nothing faster and more efficient than building C programs. I also not sure what is dangerous in having libraries. C++ is quite different though.

ODR violations are very easy to trigger unless you build the whole thing from source, and are ill-formed, no diagnostic required (worse than UB).

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

#120

Post by mgaunard »

zrm wrote: post #71
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…

> 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…

This is all wishful thinking disconnected from practicalities.

First you confuse API and ABI.

Second there is no practical difference between first and third-party for any sufficiently complex project.

Third you cannot have multiple versions of the same thing in the same program without very careful isolation and engineering. It's a bad idea and a recipe for ODR violations.

In any non-trivial project there will be complex dependency webs across different files and subprojects, and humans are notoriously bad at packaging pieces of code into sensible modules, libraries or packages, with well-defined and maintained boundaries. Being able to maintain ABI compatibility, deprecating things while introducing replacement etc. is a massive engineering work and simply makes people much less likely to change the way things are done, even if they are broken or not ideal. That's an effort you'll do for a kernel (and only on specific boundaries) but not for the average program.

Post reply on HN