Live data from Hacker News

Orthodox C++ (2016)

bkaradzic.github.io

161–170 of 238 posts

Re: Orthodox C++ (2016)

#161

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…

>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 happens when you form your opinions on half-digested ideas. Let me be clear. You don't add "a bunch" of try-catch blocks. You don't wrap every call that's capable of failing exceptionally in a try-catch block. That's exactly how you don't use exceptions. The whole point of exceptions is that the compiler will handle the stack unwinding for you so you don't need to worry about it. If you don't want to, or don't know how, or can't handle an exception at a specific point then don't. Let it bubble up for someone else to catch. See the ellipsis in my example? Inside of it you might have a gigantic call tree that performs all sorts of different operations that may all fail in different and unexpected ways. You could write the whole thing and not have a single try-catch besides the one I wrote explicitly. Let me reiterate; this is what you DON'T do:

  try{
    foo();
  }catch (...){
    return Error1;
  }
  try{
    bar();
  }catch (...){
    return Error2;
  }
  try{
    baz();
  }catch (...){
    return Error3;
  }
The only reason you would do something like this is to satisfy a specification such that you have to return different errors, specifically when each of the different calls fails. So... don't specify your functions such that you're required to do this? Just do

  foo();
  bar();
  baz();
or if you really must not throw from the function,

  try{
    foo();
    bar();
    baz();
  }catch (...){
    return SomethingFailed;
  }
TL;DR: Instead of bitching about exceptions, learn how to use them properly.

Re: Orthodox C++ (2016)

#162

Earlier quoted context omitted.

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

> having to add a bunch of random fucking try-catch bullshit around every function call Not the person you are replying to, but did you see where he said: > When exceptions are misused

That’s a No True Scotsman argument. It is not a good or useful one imho.

Re: Orthodox C++ (2016)

#163
post #8

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

“It’s so much magic! Now if you’ll excuse me, I have to go use my generic container library rewritten in 50 layers of preprocessor macros.”

Re: Orthodox C++ (2016)

#165

Earlier quoted context omitted.

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

>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 library that offers foo adds exceptions now I need to think about it at every single callsite, and probably wrap the function. It’s extremely irritating.

> learn how to use them properly.

In my 20+ years of professional C++ development I have a great experience not using exceptions and a strictly negative experience using them.

Perhaps sometimes I’ll stumble upon a library or codebase where exceptions make the code simpler, easier to understand, and easier to write. But my experience is exceptions make everything strictly worse and that not using exception is a strict win with zero downsides.

Re: Orthodox C++ (2016)

#166
post #127

Earlier quoted context omitted.

AI slop article.

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 expect from somebody that claims to have over 30 years of experience in HFT but rather point toward them being a teenager or somebody rather immature. They also make a number of wild claims that when put together, are unlikely to be true.

Sorry if you can't recognise it for what it is and shame on you if it's your website, given that you've previously submitted content from there.

Re: Orthodox C++ (2016)

#167

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…

>The fact that it compiles and runs but will behave in undesirable ways makes it even worse, not better!

* Exceptions

* Unstable API

* Incorrect behavior

Pick your poison. I know what I prefer.

>But if your library that offers foo adds exceptions now I need to think about it at every single callsite

You really don't. Like I said, it's kind of the whole point of exceptions.

>In my 20+ years of professional C++ development I have a great experience not using exceptions and a strictly negative experience using them.

Hence my recommendation to learn how to use them. I can replace "exceptions" with anything else (computers, diesel engines, HR people), and there's probably someone who holds that belief. That doesn't make it true.

And GTFO with that No True Scotsman nonsense. That a tool can be misused doesn't delegitimize the tool. If you saw someone using classes instead of namespaces you wouldn't conclude classes are bad, you'd call that person a knobhead.

Re: Orthodox C++ (2016)

#168

Earlier quoted context omitted.

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. Yes, you're unable to know what exceptions a function may throw. That's the way it should be, because exceptions aren't supposed to be part of the function's contract. For example, you're implementing an arithmetic operator and have reached an erroneous state, but…

> Throwing an exception and letting it unwind the stack way up (perhaps even all the way up to main()) is the sensible solution No. I would never in a million years do this. 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. Saying throw an exception an…

> Saying throw an exception and bubble up to main provides just about zero value. Might as well just call std::abort. Which is also something I would never do.

I'm sorry but this is where you're clearly wrong. The whole point is unwinding doesn't have to necessarily happen all the way to main(); there is a ton of value in doing this, and it is not at all equivalent to aborting. It lets someone in the call chain do something other than abort, or clean up stuff that they otherwise might not have a chance to. Like logging an error, telling the client there was an internal error, dumping additional information that wouldn't be useful in the successful case, and/or moving on to another task. All gracefully, without any intermediate functions having to care (aside from providing basic exception safety), and without having to throw your hands up and give up. Aborting without being asked is rather presumptuous and robs your callers of all opportunities to do anything about the problem you encountered.

People do this stuff and find it useful... you're effectively telling them all that they're doing something useless and they may as well just abort. That's... quite a claim.

Re: Orthodox C++ (2016)

#169

Earlier quoted context omitted.

I won't, because obviously I have. Coincidentally, I've just spent more than a day to find a sane way to setup basic windowing and rendering on Windows for the 1000st time -- this time based on Direct3D compute shader and DirectComposition. Going to integrate the Direct2D/DirectWrite backend of my UI library with those technologies in a bit. And I'm working on this project because the material removal simulation libr…

We're talking about names. Names like "Rectangle" and "Point" (thanks, Apple). It's a bit like concrete - there's two kinds (of programmers): the ones who have experienced namespace issues (i.e. name collisions) and the ones who haven't, yet.

As most, I have indeed not encountered collisions, yet, not that I could remember anything serious (I remember a macro called sth like WIN32_NO_MINMAX though).

A name like "Rectangle" will only have collisions if there is a C file that simultaneously includes headers from two distinct libraries that define that name, which frankly is very unlikely and very easy to work around. As long as you don't define a silly constructor that creates a symbol Rectangle::Rectangle(float, float, float, float) or whatever, there will not even be linker collisions when distinct parts of a software include distinct definitions of the Rectangle name.

Nevertheless, I simply name my types like "VxRect" or whatever in case they are supposed to be consumed by other components. Much better than Vx::Rect or even Company::Math::Types::Rect, isn't it?

Re: Orthodox C++ (2016)

#170
> Don’t use RTTI.

That's the core feature of the language. Not using it doesn't make any sense.

> Don’t use stream (, , etc.), use printf style functions instead.

printf is type-unsafe and bug-prone. Also modern C++ standards have better formatting utilities.

> Don’t use anything from STL that allocates memory, unless you don’t care about memory management.

In 99.9% of the time one should not care. Using something like std::vector is perfectly fine.

Overall I find such "Orthodox" C++ harmful. I call it "pure C heresy".

Post reply on HN