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

121–130 of 238 posts

Re: Orthodox C++ (2016)

#121

Post by PaulDavisThe1st »

jstimpfle wrote: post #107
PaulDavisThe1st wrote: post #90

Earlier quoted context omitted.

tell me you never use platform-provided or third party libraries without actually telling me.

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.

Re: Orthodox C++ (2016)

#122

Post by dwattttt »

rfgplk wrote: post #47
lelele wrote: post #25

Earlier quoted context omitted.

> y'know you can check if an operator has been overloaded And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.

But isn't this a problem with all code? Looking at a Rust function signature how can you be sure that it does what it says it does? Or python?

To the extent that one doesn't try to suppress compiler warnings & errors / actively break the language, you get what the compiler confirms is true about a function signature.

For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.

Re: Orthodox C++ (2016)

#123

Post by PaulDavisThe1st »

badsectoracula wrote: post #95
PaulDavisThe1st wrote: post #2

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.

> 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 more.

Re: Orthodox C++ (2016)

#124

Post by PaulDavisThe1st »

forrestthewoods wrote: post #112
PaulDavisThe1st wrote: post #86

Earlier quoted context omitted.

> This is allowed by Orthodox C++ I can see no rationale for this whatsoever. It is nothing but syntactic sugar. > Branmir (of BGFX fame Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++, and what a game dev has to say about the language in their own work might be of passing interest but not much more. Being aware of the pitfalls of particular features of…

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 point much.

TFA is not about someone sharing their preferences. It's a direct call to not use many features, and claiming that to do otherwise is a mistake. Here's an example of sharing preferences:

"I've often tried to use C++'s variadic function templates, but I've found that just using initializer lists tends to be simpler and more readable".

Here's an example of how TFA would put that:

"do NOT use variadic function templates"

Re: Orthodox C++ (2016)

#125

Post by canyp »

PaulDavisThe1st wrote: post #88
canyp wrote: post #56

My codebase uses a fairly dumbed down version of C++, but I would have liked to see more depth in this post. As it is, it is not very useful. There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be... The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and th…

> There are many more things to avoid than just iostream. But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.

doesn't require iostream.

Re: Orthodox C++ (2016)

#126

Post by canyp »

gpderetta wrote: post #69
canyp wrote: post #56

My codebase uses a fairly dumbed down version of C++, but I would have liked to see more depth in this post. As it is, it is not very useful. There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be... The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and th…

[from the linked article] > : Needs a major performance overhaul", acknowledging that the standard's mandated block size is too small and the design needs to be rebuilt at the next ABI break Except of course the standard does not mandate a block size. That's purely msvc picking a wrong block size and being stuck with it. The rant about lists is also nonsense.

I'm not sure about the standard part, but it does call out MS' STL in the sentence prior to what you quoted.

And why is the latter nonsense? lists have had terrible cache performance for decades now and vector is the better default choice of container.

Re: Orthodox C++ (2016)

#127

Post by canyp »

Chaosvex wrote: post #91
canyp wrote: post #56

My codebase uses a fairly dumbed down version of C++, but I would have liked to see more depth in this post. As it is, it is not very useful. There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be... The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and th…

AI slop article.

Unlike your comment, which is the pinnacle of human thought?

You are also wrong.

Re: Orthodox C++ (2016)

#128

Post by ReactiveJelly »

lelanthran wrote: post #116
rfgplk wrote: post #8

Earlier quoted context omitted.

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…

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

The regular table saw is still in the new workshop, and the new workshop adds a SawStop and another regular table saw.

Re: Orthodox C++ (2016)

#129

Post by WalterBright »

pjmlp wrote: post #82
lelele wrote: post #78

Earlier quoted context omitted.

Not really. C++ is on another level altogether: the code could be calling implicit conversion operators, the compiler could have instantiated some template code in an unforeseen way, and so on. Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of ti…

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.

Re: Orthodox C++ (2016)

#130

Post by forrestthewoods »

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…

> Which wording was vitriolic and angry?

“I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.”

The tone of all your comments reads as oddly intense imho. Perhaps not your intent. Opinions may vary.

> TFA is not about someone sharing their preferences. It's a direct call to not use many features, and claiming that to do otherwise is a mistake

Yeah that’s fine. The whole piece is an opinion piece on what someone thinks is a good approach to C++ development. There is no value in hedging every single bullet point with a bunch of flourish imho.

In game dev C++ circles nothing in this list is particularly controversial. It’s just writing down what many/most devs already did.

Post reply on HN