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

401–410 of 437 posts

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

#401

Post by mgaunard »

uecker wrote: post #353
mgaunard wrote: post #224

Earlier quoted context omitted.

C simply has less wording for it because less work has been put into it. The same problems exist.

The ODR problem is much more benign in C. Undefined behavior at translation time (~ IFNDR) still exists in C but for C2y we have removed most of it already.

You can't fundamentally solve the issue of what happens if you call a function in another TU that takes a T but the caller and the callee have a different definition of T. Whether you call that IFNDR or UB doesn't make much of a difference.

C++ mitigates that issue with its mangling (which checks the type name is the same), Rust goes the extra mile and puts a hash of the whole definition of the arguments in the symbol name.

C has the most unsafe solution (no mitigation at all).

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

#402

Post by mgaunard »

jjmarr wrote: post #312
mgaunard wrote: post #307

Earlier quoted context omitted.

It's pretty simple and works reliably as specified. I can only infer that your lack of familiarity was what made it take so long. Rebuilding GCC with specs does take forever, and building GCC is in general quite painful, but you could also use patchelf to modify the binary after the fact (which is what a lot of build systems do).

> I can only infer that your lack of familiarity was what made it take so long Pretty much. Trying to convert an existing build that doesn't explicitly declare object dependencies is painful. Rust does it properly by default. For example, I'm discovering our clang toolchain has a transitive dependency on a gcc toolchain.

Clang cannot bootstrap in the same way GCC can; you need GCC (or another clang) to build it. You can obviously build it twice to have it be built by itself (bear in mind some of the clang components already do this, because they have to be built by clang).

In general though, a clang install will still depend on libstdc++, libgcc, GCC crtbegin.o and binutils (at least on Linux), which is typically why it will refer to a specific GCC install even after being built.

There are of course ways to use clang without any GCC runtime, but that's more involved and non-standard (unless you're on Mac).

And there is also the libc dependency (and all sysroot aspects in general) and while that is usually considered completely separate from GCC, the filesystem location and how it is found is often tied to how GCC is configured.

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

#403

Post by menaerus »

aw1621107 wrote: post #399
menaerus wrote: post #390

Earlier quoted context omitted.

The example is false because that's not how you would write an expression template for given computation so the question being how is it that the optimizer is not involved is also not quite set in the correct context so I can't give you an answer for that. Of course that the optimizer is generally going to be involved, as it is for all the code and not the expression templates, but expression templates do not require…

> The example is false because that's not how you would write an expression template for given computation OK, so how would you write an expression template for the given computation, then? > Expression templates do not rely on O1, O2 or O3 levels being set - they work the same way in O0 too and that may be the hint you were looking for. This claim confuses me given how expression templates seem to work in practice?…

Look, I have just completed work on some high performance serialization library which avoids computing heavy expressions and temporary allocations all by using expression templates and no, optimization levels are not needed. The code works as advertised at O0 - that's the whole deal around it. If you have a genuine question you should ask one but please do not disguise so that it only goes to prove your point. I am not that naive. All I can say is that your understanding of expression templates is not complete and therefore you draw incorrect conclusions. Silly example you provided shows that you don't understand how expression template code looks like and yet you're trying to prove your point all over and over again. Also, most of the time I am writing my comments on my mobile so I understand that my responses sometime appear too blunt but in any case I will obviously not going to write, run or check the code as if I had been on my work. My comments here is not work, and I am not here to win arguments, but most of the time learn from other people's experiences, and sometimes dispute conclusions based on those experiences too. If you don't believe me, or you believe expression templates work differently, then so be it.

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

#404

Post by saghm »

imtringued wrote: post #397
saghm wrote: post #145

Earlier quoted context omitted.

Interesting, I didn't realize this! I know that a "crate" is specifically the unit of compilation for rustc, but I assumed there was some magic in cargo that glued the modules together into a single AST rather than it being in rustc itself. That being said, I'd argue that the fact that this happens so transparently that people don't really need to know this to use Cargo correctly is somewhat the point I was making. C…

The module system in Rust is incredibly confusing for a beginner. The standard module in Rust is basically a Rust source file ( .rs) with the name of the module or a directory with a mod.rs file inside ( /mod.rs). However, that alone doesn't make it a module. The root source file (lib.rs or main.rs) must declare that .rs is actually a module in the preamble via mod ; Thus it works "backwards" in comparison to C style…

I wouldn't exactly say that the way C/C++ headers work is particularly intuitive for beginners either; having spent several years as a TA in a course in college where students were writing C for the first time (after having used mostly Java beforehand), I've seen plenty of times where students have trouble figuring out how to properly split things between headers and "regular" source files, have trouble figuring out how to properly specify which sources to link together in their makefiles, and have to learn how to either avoid accidentally including the same thing twice transitively or use one of the various workarounds that mitigates it.

You might argue that all of these are solvable problems, but I'd argue that learning how to properly declare a module in Rust is overall a lot simpler than learning how to deal with all of the analogous problems in C/C++. For people who have never used C/C++ or Rust before, you could just as easily say that they work backwards in comparison to Rust, and in a vaccuum, I think the way Rust does it would be far more intuitive to someone who had familiarity with neither and were presented both at the same time.

As a thought experiment: if you had a group of people who didn't know either Rust or C/C++, and you split them in half, and taught half of them Rust first and C second and did the reverse for the other half, how many of the people in each group would you expect to consider the configuration of Rust builds to be more confusing than the configuration of C builds? I'd be willing to bet that you'd have a far more people in the group that you taught C first who considered Rust builds to be more intuitive than people in the other group who thought that C builds were more intuitive, and that it would be strong evidence that the build system for Rust is overall much easier to understand.

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

#405

Post by aw1621107 »

menaerus wrote: post #403
aw1621107 wrote: post #399

Earlier quoted context omitted.

> The example is false because that's not how you would write an expression template for given computation OK, so how would you write an expression template for the given computation, then? > Expression templates do not rely on O1, O2 or O3 levels being set - they work the same way in O0 too and that may be the hint you were looking for. This claim confuses me given how expression templates seem to work in practice?…

Look, I have just completed work on some high performance serialization library which avoids computing heavy expressions and temporary allocations all by using expression templates and no, optimization levels are not needed. The code works as advertised at O0 - that's the whole deal around it. If you have a genuine question you should ask one but please do not disguise so that it only goes to prove your point. I am n…

> If you have a genuine question you should ask one but please do not disguise so that it only goes to prove your point.

I think my question is pretty simple: "How does an optimizer-independent expression template implementation work?" Evidently the resources I've found so far describe "optimizer-dependent expression templates", and apparently none of the "expression template" implementations I've had reason to look at disabused me of that notion.

> My comments here is not work, and I am not here to win arguments, but most of the time learn from other people's experiences, and sometimes dispute conclusions based on those experiences too.

Sure, and I like to learn as well from the more knowledgeable/experienced folk here, but as much as I want to do so here I'm finding it difficult since there's precious little for me to go off of beyond basically just being told I'm wrong.

> If you don't believe me, or you believe expression templates work differently, then so be it.

I want to understand how you understand expression templates, but between the above and not being able to find useful examples of your description of expression templates I'm at a bit of a loss.

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

#406

Post by WalterBright »

poppadom1982 wrote: post #389
WalterBright wrote: post #376

Earlier quoted context omitted.

I don't recall anyone making a patent claim.

Open source and free software isn't the same thing. Nobody made a claim on Java either, until someone did. I just distinctly remember explicitly not exploring D for that reason. Also this way way before LLVM and I also don't think GNU had a D compiler back then. There was only the (and I really believe it was closed source) Digital Mars compiler.

15 years ago, both LLVM and GNU had a D compiler. gdc (the GNU compiler) was not an official part of the gcc collection, but it was definitely there and 100% open source.

All three compilers shared the open source D front end. The DMD backend source code was available for anyone to use, it just couldn't be redistributed. We were eventually able to fully Boost license it.

The DMD compiler always had source available for free from Digital Mars. I never sold a single copy :-)

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

#407

Post by WalterBright »

Defletter wrote: post #400
WalterBright wrote: post #153

Earlier quoted context omitted.

I implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html

But then why did you add your contract system to D? You implemented your contract system in the "early 90's", and D was released in 2001, so that's near a decade of "nobody wanted it". So then why add them as a core language feature of a new programming language if no one wanted it? Why is it still a core language feature? And why object to C++ finally adding contracts. I just don't get what you're even arguing here.

It's a great question! I simply had faith that it was a good idea.

The reason I started D in the first place is the C++ community was uninterested in any of my ideas for improvement. Ironically, C++ would up adopting a lot of them one by one! Such as contracts!

Contracts did find an enthusiastic constituency in the D community.

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

#408

Post by WalterBright »

Defletter wrote: post #398
WalterBright wrote: post #370

Earlier quoted context omitted.

35 years is a lot longer than a decade. C++ should have copied the '= void;' syntax, too!

It should copy Zig's '= undefined;' instead of D's '= void;' The latter is very confusing: why have a keyword that means nothing, but also anything? This is a pretty common flaw within D, see also: static.

Nobody in D was confused by `= void;`. People understood it immediately.

> why have a keyword that means nothing, but also anything?

googling void: "A void is a space containing nothing, a feeling of utter emptiness, or a legal nullity, representing a state of absolute vacancy or lack."

Sounds perfect!

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

#409

Post by MaxBarraclough »

tialaramex wrote: post #310
kwsp wrote: post #293

Earlier quoted context omitted.

I don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?

I can't tell if you imagine std::optional is a value (it is not) or if you know it's a templated type but you imagine that somehow it would be OK to redefine all programs so that every type is std::optional of that type instead so as to simplify initialization. Either way no, that can't work.

> Either way no, that can't work.

Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine.

I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?

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

#410

Post by steveklabnik »

inetknght wrote: post #385
steveklabnik wrote: post #320

Earlier quoted context omitted.

It is easier to design the software so that you don't have confusing behavior when you're not required to include behaviors you don't want. Most things do not need to be nullable. Requiring all things to have a zero value, even when they do not have one, makes it harder to be correct by construction, not easier.

> It is easier to design the software so that you don't have confusing behavior when you're not required to include behaviors you don't want. It can be easier, but not always. But it is almost always a better design. Redesigning software so that whole classes of problems simply can't exist is absolutely better than software that needs to handle all kinds of problems. Many of those problems might not even ever happen…

I agree that you want to require a correctly-constructed value. The entire point I'm making is that in languages with zero values, this is hard, because that zero value may not be valid for your domain.

Languages with pervasive nullability effectively gives everything a zero value.

Post reply on HN