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

181–190 of 238 posts

Re: Orthodox C++ (2016)

#181

Post by uecker »

pjmlp wrote: post #174
lelanthran wrote: post #114

Earlier quoted context omitted.

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.

The license is indeed the big reason for many proprietary forks (not so much that llvm is written in C++). This is not a good thing though.

Re: Orthodox C++ (2016)

#182

Post by jcelerier »

patrick451 wrote: post #68
dataflow wrote: post #23

Earlier quoted context omitted.

> build a fort to deflect the random exceptions they'll throw at you Sounds like you hate exceptions, right? In which case why do you handle them at all? Just leave them all unhandled and suddenly every exception is a crash. Which is really no different from someone choosing to terminate. Which you have to worry about even without exceptions. > if you have a C++ code base yet somehow have enough time and energy to wr…

> Which is really no different from someone choosing to terminate. If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.

> If you crash from an unhandled exception, you don't.

.. you absolutely get a stack trace from unhandled exception in c++, that starts where the exception is thrown? At least with clang and GCC, maybe MSVC isn't able to.

foo.cpp:

    #include
running:

    $ g++ foo.cpp -std=c++23 -g
    $ ./a.out
    terminate called after throwing an instance of 'std::runtime_error'
      what():  boo

    $ coredumpctl gdb
    ...
    #7  0x00005555555551bb in bar () at foo.cpp:3
    #8  0x00005555555551da in foo () at foo.cpp:4
    #9  0x00005555555551e6 in main () at foo.cpp:5
it's a basic example, but it's how I've always done all my debugging in C++ since forever

Re: Orthodox C++ (2016)

#183

Post by jcelerier »

forrestthewoods wrote: post #165
fluoridation wrote: post #161

Earlier quoted context omitted.

>If I am choosing to change the API contract then someone who wants to use the new API has to update. This is not a big deal. Throwing lets you handle the new situation without changing the API at all. >Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design. See, that's what happ…

> Throwing lets you handle the new situation without changing the API at all. I do not disagree. https://xkcd.com/1172/ If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code. The fact that it compiles and runs but will behave in undesirable ways makes it even worse, not better! > or if you really must not throw from the function, I’m aware. But if your libr…

> If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code.

No, that's the whole point. You let them bubble up to the top of the event loop and you report the error to the user. As a user, anything else leads to shitty software where the programmer tries to outsmart the world around them (and fails, obviously, leading to worse end-user experience than just admitting that you don't and can't have control over everything)

Re: Orthodox C++ (2016)

#184

Post by Chaosvex »

ephimetheus wrote: post #180
Chaosvex wrote: post #166

Earlier quoted context omitted.

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.

What are you talking about? Are you claiming ~two weeks ago predates LLMs or am I misinterpreting what you're trying to say?

Re: Orthodox C++ (2016)

#185

Post by flohofwoe »

fluoridation wrote: post #135
lelanthran wrote: post #116

Earlier quoted context omitted.

All the foot guns in C are still in C++, and C++ adds a significant multiple more.

Literally untrue. Two words: stronger typing.

Memory corruption magnets like iterator invalidation, std::string_view or std::span are on a whole different level than the footguns that were inherited from C. At least with C style raw pointers you know that you have to be careful when you see one, in C++ the unsafety is lurking in hidden places sprinkled all over the stdlib and comes in all shapes and forms.

Re: Orthodox C++ (2016)

#186

Post by flohofwoe »

PaulDavisThe1st wrote: post #124
forrestthewoods wrote: post #112

Earlier quoted context omitted.

Your level of vitriol and anger at someone expressing an opinion is really weird. Literally everyone who uses C++ decides which features to use/embrace and which to avoid. Someone sharing their particular preference is pretty normal and fine. > Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++ I love how you reject appeal to authority and then try to estab…

Which wording was vitriolic and angry? I wasn't seeking to establish my own authority in any way: "X is brilliant, we should listen to them" being countered by "there are lots of people with similar levels of experience with this thing who have many different opinions (I happen to be one of them)" isn't an appeal to authority. But sure, I could have left out the ("I happen to be one of them") part without changing my…

> It's a direct call to not use many features, and claiming that to do otherwise is a mistake.

I think you are thouroughly misunderstanding the blog post. It's not an aggressive "you must start using this now" thing, but mainly a definition of what "Orthodox C++" is so that communication about coding styles is simplified.

When somebodies says "this project is using the Orthodox C++ style" then it is immediately clear to everybody what exactly that entails (and if not they can google the term it and find the blog post). It's also a counter proposal to some of "Modern C++" madness (like "almost always auto") that was all the rage around a decade ago when that post was first written.

FWIW I wrote a fairly similar blog post in 2013 to describe what our team coding style looked like back then:

https://floooh.github.io/2013/06/21/sane-c.html

(PS: back then I still thought that C++ could be salvaged)

Re: Orthodox C++ (2016)

#187

Post by delta_p_delta_x »

jstimpfle wrote: post #105
delta_p_delta_x wrote: post #93

Earlier quoted context omitted.

> anything serious, i.e. high throughput, low frequency, massively concurrent work Why is only 'high throughput, low frequency, massively concurrent work' considered 'serious'?

You are free to make your own definition, what are your suggestions? (Obviously I meant to say low latency, not low frequency)

That is a cop-out. You made the assertion, you define it.

What about these particular workloads (and the environments they're used in) make them 'serious' and why are other workloads 'lesser' and therefore the standard library 'suffices'? Why not use better containers for everything? Google, for instance, universally recommends Abseil.

Re: Orthodox C++ (2016)

#188

Post by tialaramex »

jstimpfle wrote: post #176
tialaramex wrote: post #134

Earlier quoted context omitted.

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

As with the likely/ unlikely branch hint the problem is that programmers are wrong much more often than they expect on both sides. They're too often wrong to think they know the final size - hence Bjarne's caution - but they're also too often wrong that they've got no idea how much capacity they need at all. So hence this API.

You're correct that this isn't a huge optimization. But it more than pulls its weight directly because it's a small boon when you're right and it doesn't have the terrible penalty that Vec::reserve_exact has when inevitably the programmer is sometimes wrong. It's very much about saving pennies, but the growable array type is so widely used that counting pennies makes sense.

I have a lot more thoughts about reservation, but these suffice for specifically the growable array type.

Re: Orthodox C++ (2016)

#189

Post by xigoi »

forrestthewoods wrote: post #157
fluoridation wrote: post #153

Earlier quoted context omitted.

>If the API is that a function is infallible and then I decide that it’s a fallible function then that’s a pretty major change and I’m just gonna have to update all the call sites to deal with a fallible return result. What if you don't control those call sites? >Might as well just call std::abort. Sure. I mean, not really, because the caller cannot handle an abort. You're making a decision for the caller that the si…

> What if you don't control those call sites? If I am choosing to change the API contract then someone who wants to use the new API has to update. This is not a big deal. > If the function doesn't use exceptions for normal error conditions, then no, it's not a new contract I disrespectfully and emphatically disagree. I do not accept your definition of contract. > You could do something like (try-catch wrapper) Let me…

> Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design.

The whole point of exceptions is that you don’t need to handle errors at every call site. You can just have one central try-catch block at a place where you have a way to deal with the error, such as report it to the user.

Re: Orthodox C++ (2016)

#190

Post by throwaway173738 »

jcelerier wrote: post #182
patrick451 wrote: post #68

Earlier quoted context omitted.

> Which is really no different from someone choosing to terminate. If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.

> If you crash from an unhandled exception, you don't. .. you absolutely get a stack trace from unhandled exception in c++, that starts where the exception is thrown? At least with clang and GCC, maybe MSVC isn't able to. foo.cpp: #include running: $ g++ foo.cpp -std=c++23 -g $ ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): boo $ coredumpctl gdb ... #7 0x00005555555551bb in bar ()…

Sure, in a desktop program you do. In embedded exceptions are a scourge because they crash your program until someone can get back out there to power cycle it. At least with return-codes you can continue execution even if you failed to effect the change you wanted. If that was ancillary to the system’s core function then the system keeps running.
Post reply on HN