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

Orthodox C++ (2016)

bkaradzic.github.io

Post reply on HN
Print view View original

171–180 of 238 posts

Re: Orthodox C++ (2016)

#171

Post by jstimpfle »

tialaramex wrote: post #134
jstimpfle wrote: post #120

Earlier quoted context omitted.

To be fair grow-but-don't-initialize is a pretty fundamental part of the API, the reserve() method. But already the basic premise that you should push back without thinking is wrong. You will suffer reallocations and invalisations when you least expected them, and frankly you have to architect around that fact which is a terrible restriction. You can work around by pre reserving but at that point it's just a basic fi…

std::vector lacks what I call the "bifurcated reservation API". It has Rust's Vec::reserve_exact but not Vec::reserve -- these APIs serve subtly different purposes, the former (which C++ calls just "reserve") says "Here's a hint for exactly how big this container will ever grow" while the latter says "Here's a hint for how big this container will get in my immediate future, but it might grow further later". The imple…

Feels like typical improvement/perfection tunnel vision syndrome to me, though. That syndrome is engrained in C++ community and I think also Rust community, although it looks like the latter took the chance to do many things better from the start learning from C++'s mistakes.

Realloc is pretty much never the right way in whatever form, and I've never seen any need to include realloc in any of my own allocators (mostly blockallocators and linear allocators and pools/free lists, sometimes using malloc/free).

Re: Orthodox C++ (2016)

#172

Post by dataflow »

fluoridation wrote: post #159
dataflow wrote: post #156

Earlier quoted context omitted.

I think you missed my point. I was referring to the fact that some of these standard exceptions are very much a part of the contracts of their respective functions. In fact, that's their entire point. This directly contradicts what you wrote.

You're using "contract" in a different sense than I did. When I said "contract" I was referring to the required state of the program when the function is called and the guaranteed state of the program when the function returns. By definition an exception cannot be part of the contract in this sense, because a call that throws does not return. This narrower sense of contract is critical, because the entire point of ex…

Okay, but if I may offer a suggestion: in the future, I would probably phrase what you said differently. I think it caused you trouble here not just with me but with other readers. Instead of "when the function cannot fulfill its contract", I would talk about "when returning would not fulfill a function's contract."

There are actually two reasons for this, not one:

- It violates standard terminology. The notion of a contract/postcondition/etc. is not specific to C++ or the particular implementation's mechanisms for exiting a function. It simply means a condition that must hold true after the execution of some piece of code. [1] The intent of this definition is to allow program composition: it enables one to reason about the greater program in terms of the sub-parts. Defining it to be anything else just throws people off, and rather misses the point and utility of the term.

- "Cannot" is actually too strong. A function might, in fact, be able to fulfill its contract, but still choose not to. An easy example is something like a constraint solver (SAT, chess, simulator, constexpr evaluator, or whatever). It's guaranteed to be able to find the solution eventually if it keeps going, but that's probably not always a good idea.

Now, going back to what you wrote here:

> Exceptions aren't meant to report errors, just in general. That's a misuse of them. Exceptions are meant to be thrown when a contract cannot be fulfilled.

I'm still not entirely sure I see what you mean by "report errors". How exactly have you seen people use exceptions to "report errors" that is not for the purpose of indicating that "a contract cannot be fulfilled"? The description makes it sound like using exceptions for the purpose of logging, but that would seem like a strawman... I have never seen anyone write throw instead of log. What are you referring to?

[1] https://en.wikipedia.org/wiki/Postcondition

Re: Orthodox C++ (2016)

#173

Post by pjmlp »

uecker wrote: post #104
pjmlp wrote: post #100

Earlier quoted context omitted.

Naturally GCC was originally written in C, given its age, and the original GNU coding standards document. With time, the GCC developers acknowledged the benefits of using C++ over C, and migrated the code. GCC requires a C++ compiler to bootstrap since around 2012, and GNU coding standards has been updated to several languages beyond C, time to go up with times.

I think the fallacy of this argument is obvious.

Not really, given that GCC no longer compiles with a pure C compiler.

Unless of course, you don't have anything to do, and feel like bootstraping GCC 16, using a compiler chain all the way back to 2012 thereabouts.

Re: Orthodox C++ (2016)

#174

Post by pjmlp »

lelanthran wrote: post #114
delta_p_delta_x wrote: post #98

Earlier quoted context omitted.

Clang/LLVM with its more permissive licence sees _much_ wider use and is written purely in C++. PlayStation, automotive, platforms and runtimes like Chromium/V8, Android, etc. are all built with Clang.

Clang usage is a fraction of GCC usage. Regards, an embedded dev.

A decade ago surely, in 2026 I doubt it.

With Android, iDevices, PlayStation, Switch, and everyone that had proprietary compilers down using downstream forks from clang, due to the more appealing license.

Who is left still using GCC, other than existing projects lacking a clang backend for a snowflake embed CPU?

In any case, if it is a modern GCC release past 2012, it was compiled with C++ as well.

Re: Orthodox C++ (2016)

#175

Post by pjmlp »

WalterBright wrote: post #129
pjmlp wrote: post #82

Earlier quoted context omitted.

I suppose you're aware C# also has implicit conversion operators, operator overloading, reflection, aspect oriented programming, compiler plugins, interceptors. Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead. You catch pitfalls in any language the same way, using static analysis, which C authors…

In D, we've introduced editions so that obsolete, problematic, or redundant features can be removed.

Finally happened! Thanks for the heads up.

Yeah C# is getting a bit unwidely.

Re: Orthodox C++ (2016)

#176

Post by jstimpfle »

tialaramex wrote: post #134
jstimpfle wrote: post #120

Earlier quoted context omitted.

To be fair grow-but-don't-initialize is a pretty fundamental part of the API, the reserve() method. But already the basic premise that you should push back without thinking is wrong. You will suffer reallocations and invalisations when you least expected them, and frankly you have to architect around that fact which is a terrible restriction. You can work around by pre reserving but at that point it's just a basic fi…

std::vector lacks what I call the "bifurcated reservation API". It has Rust's Vec::reserve_exact but not Vec::reserve -- these APIs serve subtly different purposes, the former (which C++ calls just "reserve") says "Here's a hint for exactly how big this container will ever grow" while the latter says "Here's a hint for how big this container will get in my immediate future, but it might grow further later". The imple…

Vec::reserve() is the behaviour you get from C++ std::vector push_back() (implicit just-in-time reserve), so right now I can't see a situation where I'd want the explicit Rust version even if I didn't think the whole push realloc thing is mostly a bad idea.

Yes, Rust version allows you to maybe skip a reallocation step or two by doing explicit up front reallocation. But remember most allocation work is always from the last grow anyway. The Rust version seems like a microoptimization, giving a little bit more explicit control in a situation where you've already pretty much given up control and gone like, throw hands in the air, we're doing push_back()!

Re: Orthodox C++ (2016)

#177

Post by dataflow »

forrestthewoods wrote: post #146
dataflow wrote: post #143

Earlier quoted context omitted.

> One of the problems with exceptions is it’s utterly impossible to know if a given function call can return exceptions and if so what they are. Could you please explain how exactly you know if a function might abort? And how you figure out exactly which error codes a function might return if it does return an error? And why/how your techniques for figuring out the above don't work for exceptions? > Python is the blo…

Functions aborting is not something I’ve ever really had to think about. Exception heavy codebases it’s something I have to ALWAYS think about. Error codes are pretty bad. Global error code is awful. An error enum is pretty nice. So here’s the thing. I’ve been a professional C++ programmer for 20 years. Not once have I ever worked in a codebase that used exceptions. It’s fine. Occasionally I use a thirdparty library…

> Functions aborting is not something I’ve ever really had to think about.

There are certainly a lot of programs for which it matters a whole lot. In a lot of applications you absolutely don't want your program to crash. I'm not even talking about rocket launching or pacemakers or HFT here... I just mean something as simple as a web server or job server. It's the difference between taking down the server (say, getting DoS'd) vs. not.

> So here’s the thing. I’ve been a professional C++ programmer for 20 years. Not once have I ever worked in a codebase that used exceptions. It’s fine.

I work on codebases without exceptions too; it's not just you. "It's fine" in the same sense that working with a messy desk or floor "is fine". One certainly can live with it -- especially when there's no better option available -- but the clutter gets in the way, distracts you, and sometimes leaves you with a little papercut.

> Occasionally I use a thirdparty library that does use exceptions and it’s bloody awful.

You're not wrong -- this can certainly happen -- but I think you've misidentified the problems. There are other reasons for this than what you've listed in [1] or that I have the energy to fully expand on here, but the biggest one is probably the fact that you're getting the worst of both worlds by the mere virtue of mixing them. Nobody claimed that mixing code that uses exceptions with code that assumes they're disabled would lead to a good outcome. It neither lets you simplify the problem by assuming exceptions will work like they're supposed to, nor does it let you simplify the problem by assuming exceptions are nonexistent. It's like putting cars and bicycles on the same sections of the road all over the town. It's going to lead to more crashes than if you had just stuck with one or the other, and that's not because cars or bikes inherently suck.

[1] https://news.ycombinator.com/item?id=48522500

Re: Orthodox C++ (2016)

#178

Post by uecker »

PaulDavisThe1st wrote: post #139
uecker wrote: post #96

Earlier quoted context omitted.

I was programming in C++ before switching to C and I would say that C++ adds a huge amount of mental load compared to C. I think one can understand how much of a relieve it is to not worry about everything C++ does only after not using C++ for a quite a while.

Any time I go back to C from C++, it's only comfortable if I've got a C utility library that replaces most of std:: And that utility library (there are dozens of them) is just as subject to debate and issues as libstdc++ I am not going to implement my own C versions of 90% of the stuff std:: provides, sorry.

There is a difference between "needing a library" and "implement my own". One can just pick one. And even when implementing things yourself, one has to do this just once.

Re: Orthodox C++ (2016)

#179

Post by uecker »

pjmlp wrote: post #173
uecker wrote: post #104

Earlier quoted context omitted.

I think the fallacy of this argument is obvious.

Not really, given that GCC no longer compiles with a pure C compiler. Unless of course, you don't have anything to do, and feel like bootstraping GCC 16, using a compiler chain all the way back to 2012 thereabouts.

The question is whether GCC is a good example of the benefits of C++ for compilers. Considering the code looks to 95% like C code and uses data structures that we originally implemented in C, I don't see this argument.

Re: Orthodox C++ (2016)

#180

Post by ephimetheus »

Chaosvex wrote: post #166
canyp wrote: post #127

Earlier quoted context omitted.

Unlike your comment, which is the pinnacle of human thought? You are also wrong.

I'm not wrong. It's been removed elsewhere for being LLM generated. This discussion has already been had multiple times. The author used Claude to generate it and instructed it to intentionally insert mistakes. They had comments posted on Reddit that discussed doing this and their account is a slew of AI generated responses. The short responses where it appears they didn't use AI don't reflect the behaviour you'd exp…

Funny this predates even the original paper first introducing the attention mechanism underpinning modern LLM.
Post reply on HN