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

211–220 of 238 posts

Re: Orthodox C++ (2016)

#211

Post by fluoridation »

forrestthewoods wrote: post #209
fluoridation wrote: post #208

Earlier quoted context omitted.

>Let’s say I have a physics system that runs an update. Assume we catch outside the update. If anything throws the system is now in an intermediate state and is effectively irrecoverable. That's a transaction kind of scenario. You catch at a recoverable point and rollback to a good state, and if that's not possible, then you simply fail out. I don't understand; what problem did exceptions introduce here? An exception…

> All else being equal, exceptions make this kind of code better by making it more readable. I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable . There’s a reason that literally no modern systems language has adopted C++ exceptions. We’re just about at the point of discussing syntactic sugar. So one q…

>I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable.

That's cool. I disagree that the principal control path should be made more difficult to read in favor of having really explicit error handling that doesn't actually do anything. That said, I do like Rust's question mark operator; it's a pretty cool middle ground between exceptions and error codes.

So, about that example of exceptions introducing faulty behavior unrelated to resource management that I asked for?

Re: Orthodox C++ (2016)

#212

Post by forrestthewoods »

fluoridation wrote: post #211
forrestthewoods wrote: post #209

Earlier quoted context omitted.

> All else being equal, exceptions make this kind of code better by making it more readable. I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable . There’s a reason that literally no modern systems language has adopted C++ exceptions. We’re just about at the point of discussing syntactic sugar. So one q…

>I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable. That's cool. I disagree that the principal control path should be made more difficult to read in favor of having really explicit error handling that doesn't actually do anything. That said, I do like Rust's question mark operator; it's a pretty cool…

> example of exceptions introducing faulty behavior unrelated to resource management that I asked for?

Well there’s a reason that constructors aren’t allowed to throw. Because it would leave objects in a weird hybrid state.

My physics system example would be the canonical one. You have a system that is transforming from one state to the next. An exception is thrown in the middle of the state transition. Whatever invariants you had for either state is (plausibly) not held. I believe your solution to this was to treat it as a transaction and rewind/restore to the previous state if an error is encountered.

It’s difficult because I would simply literally never use exceptions for anything ever. My experience with them is strictly negative with zero positives of any kind. I genuinely can not think of a single thing they make better. Nor have I ever encountered a library or codebase where I felt exceptions made it better. But boy howdy have I been frustrated by exceptions.

boost often has two APIs one with exceptions and one with error code reference arguments. I intend to always use the EC version. And god damn is it fucking frustrating when I accidentally use the exception version and so I get a runtime exception for a vanilla error that I wasn’t expecting. Which is why hidden control flow is evil!

Re: Orthodox C++ (2016)

#213

Post by badsectoracula »

PaulDavisThe1st wrote: post #123
badsectoracula wrote: post #95

Earlier quoted context omitted.

> for (auto const & ess : esses) { The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know. Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) b…

It doesn't matter what the type is, that's the whole point! Moreover, what's even more beautiful? You can change the type of things in the container "esses", and the code doesn't need to change. If you have the experience, this construct tells you everything you need to know: it's an iteration over a container, visiting every element in order, without copying it, and without modifying it. You don't need to know any m…

> It doesn't matter what the type is, that's the whole point!

Except it often does.

> You don't need to know any more.

I need to modify and/or review the code so, yes, i do need to now more.

Re: Orthodox C++ (2016)

#214

Post by badsectoracula »

preg_match wrote: post #136
badsectoracula wrote: post #95

Earlier quoted context omitted.

> for (auto const & ess : esses) { The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know. Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) b…

C++ is an IDE type language in my opinion. C is not, because C doesn’t have an expressive enough type system anyway to justify it. Yes, just use and IDE. This is a problem in Rust as well. And C#, Java, and others. IMO you should use auto as much as possible. If the code can be written with auto, it should be. There’s no reason to repeat type definitions. If you can use auto, what that means is the type is already st…

> Yes, just use and IDE

The best the IDE can do is display a tooltip or something like that which is cumbersome when reading the code because you need to move over everything to figure out what the types are. And sometimes for whatever reason even that fails.

And this is only useful in the context of using an IDE: code can be found outside IDEs too, even if all you do is use an IDE for your development (not everyone does), the code can still be found in patch files, pull requests and code review platforms none of which have any IDE functionality to know what the types are.

> There’s no reason to repeat type definitions. If you can use auto, what that means is the type is already statically known

I'm not a compiler though.

Re: Orthodox C++ (2016)

#215

Post by fluoridation »

forrestthewoods wrote: post #212
fluoridation wrote: post #211

Earlier quoted context omitted.

>I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable. That's cool. I disagree that the principal control path should be made more difficult to read in favor of having really explicit error handling that doesn't actually do anything. That said, I do like Rust's question mark operator; it's a pretty cool…

> example of exceptions introducing faulty behavior unrelated to resource management that I asked for? Well there’s a reason that constructors aren’t allowed to throw. Because it would leave objects in a weird hybrid state. My physics system example would be the canonical one. You have a system that is transforming from one state to the next. An exception is thrown in the middle of the state transition. Whatever inva…

>It’s difficult because I would simply literally never use exceptions for anything ever. My experience with them is strictly negative with zero positives of any kind.

So what I'm getting is that you don't have enough experience with exceptions to judge whether a bug related to exceptions is caused by the code not being exception-safe, thus leaking resources after a throw; by exceptions being thrown for non-exceptional error conditions, thus necessitating excessive try-catching; or by plain old incorrect error handling, thus resulting in trashed program state. So when you encounter a bug like this, instead of figuring out what the actual problem is, you just hack away until there are no more exceptions in sight, and then you actually start to work on fixing the logic. Well, if you're comfortable remaining ignorant and pretending that a language feature doesn't exist, then have at it, I guess.

>boost often has two APIs one with exceptions and one with error code reference arguments. I intend to always use the EC version.

I don't like the throwing versions, either, and consider them examples of how not to use exceptions. I'd have to think carefully of a counterexample, but in general I'd say it's a bad idea to throw across library boundaries.

Re: Orthodox C++ (2016)

#216

Post by forrestthewoods »

fluoridation wrote: post #215
forrestthewoods wrote: post #212

Earlier quoted context omitted.

> example of exceptions introducing faulty behavior unrelated to resource management that I asked for? Well there’s a reason that constructors aren’t allowed to throw. Because it would leave objects in a weird hybrid state. My physics system example would be the canonical one. You have a system that is transforming from one state to the next. An exception is thrown in the middle of the state transition. Whatever inva…

>It’s difficult because I would simply literally never use exceptions for anything ever. My experience with them is strictly negative with zero positives of any kind. So what I'm getting is that you don't have enough experience with exceptions to judge whether a bug related to exceptions is caused by the code not being exception-safe, thus leaking resources after a throw; by exceptions being thrown for non-exceptiona…

Very rude. I have not personally attacked you a single time.

Re: Orthodox C++ (2016)

#217

Post by fluoridation »

forrestthewoods wrote: post #216
fluoridation wrote: post #215

Earlier quoted context omitted.

>It’s difficult because I would simply literally never use exceptions for anything ever. My experience with them is strictly negative with zero positives of any kind. So what I'm getting is that you don't have enough experience with exceptions to judge whether a bug related to exceptions is caused by the code not being exception-safe, thus leaking resources after a throw; by exceptions being thrown for non-exceptiona…

Very rude. I have not personally attacked you a single time.

That wasn't an attack, it was an objective statement. If you think I'm wrong then feel free to correct me.

Re: Orthodox C++ (2016)

#218

Post by DarkUranium »

throwaway173738 wrote: post #191
jcelerier wrote: post #183

Earlier quoted context omitted.

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

What user? I work on systems where there might not be a keyboard or a mouse or a display and where the use of there is one doesn’t care that the “flooblutz was out of turving.” The only thing stack unwinding gets me is it forces me to restart my program from the beginning.

Addendum: I, for one, have used software that would constantly show exception-related error message dialogs.

Hell, I'm forced to use such software at work because we're (at least for now) stuck with a horrible legacy vendor.

It is not fun. So, no, "just show it to the userand let them decide" doesn't actuality resolve anything either.

Re: Orthodox C++ (2016)

#219

Post by forrestthewoods »

fluoridation wrote: post #217
forrestthewoods wrote: post #216

Earlier quoted context omitted.

Very rude. I have not personally attacked you a single time.

That wasn't an attack, it was an objective statement. If you think I'm wrong then feel free to correct me.

Thanks for the conversation. But I think I’m done here. Cheers.

Re: Orthodox C++ (2016)

#220

Post by DarkUranium »

flohofwoe wrote: post #186
PaulDavisThe1st wrote: post #124

Earlier quoted context omitted.

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…

Fancy running into you here.

Anyway, as it turns out, while the STL container situation is better than it was, it's still really terrible performance-wise.

So even nowadays, you're better off writing your own containers for performance-critical tasks; the benefits can be in orders of magnitude (depending on the task at hand, of course).

Post reply on HN