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

51–60 of 238 posts

Re: Orthodox C++ (2016)

#51

Post by pjmlp »

01100011 wrote: post #15
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…

A lot of us are too busy solving problems. Learning about the latest language features, which we often won't be able to use anyway due to the trouble of moving a large dev environment to a newer standard, feels like academic masturbation. C++ folks are very much into their language, and can't seem to understand that most folks don't want to dedicate significant amounts of mental resources purely to language details.

Like implementing the compilers used by C devs.

Re: Orthodox C++ (2016)

#52

Post by wglb »

kabdib wrote: post #31

I've been doing embedded systems in C++ since rocks were young, and this is a great summary of what to avoid. I would sure love a good coroutine runtime, and first-class support for defer. You can do these manually, but language/toolchain/debugger support is nice to have. (Pragmatically, I will be retired by the time they would be useful)

It is still a bit amazing to me that it was significantly easier to do coroutines in Sigma 5 assembly and likely most any assembly than in C or C++. Two languages supposedly close to the machine.

Re: Orthodox C++ (2016)

#54

Post by ndiddy »

rfgplk wrote: post #16

This is gonna be a long critique, I'll try to keep it concise. > C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities. C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). The…

> When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).

In C, you can use goto to jump over a variable declaration, and you can't in C++. I understand why this is, but it's the thing I see the most often that makes C code not compile as C++.

Re: Orthodox C++ (2016)

#55

Post by ok123456 »

stringstreams and fmt are a godsend compared to printf/scanf, which have historically led to most memory bugs in the first place!

Printf/scanf are implemented as variadic functions without type checking and rely on the compiler to perform its own internal metaprogramming to inspect and warn about format mismatches.

Anyone advocating the use of the old cstdio as a primary design decision about which C++ language features to use is not serious.

No exceptions or RTTI make sense in an embedded system that needs to ensure determinism, but are arbitrary and unnecessarily hobbling for high-level systems and application programming. How do you do runtime method dispatch without creating vtables and RTTI from first principles? How do you propagate a runtime error deep from the bowels of a component all the way to some top-level event loop? The "orthodox" approach would be a mess of integer return codes with associated enums (and none of that enum class nonsense!). No Thanks. It's clear the author has no idea what he's talking about.

Re: Orthodox C++ (2016)

#56

Post by canyp »

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 the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument.

And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.

Re: Orthodox C++ (2016)

#57

Post by bluGill »

01100011 wrote: post #15
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…

A lot of us are too busy solving problems. Learning about the latest language features, which we often won't be able to use anyway due to the trouble of moving a large dev environment to a newer standard, feels like academic masturbation. C++ folks are very much into their language, and can't seem to understand that most folks don't want to dedicate significant amounts of mental resources purely to language details.

Moving to new C++ is a non event, change the compiler / flags and done. Using the new features requires some learning but not a big deal since you can figure out what you need from a summary and learn what is useful for your problem.

The problems of the code I'm writing far exceeds the complexity of the language. Your complaint about complexity fall flat to me, unless you are working on a trivial program you need to deal with things far more complex than any language.

Re: Orthodox C++ (2016)

#58

Post by wavemode »

rfgplk wrote: post #45
jstimpfle wrote: post #42

Earlier quoted context omitted.

Trust me, I know more C++ than most or all of my peers (working two jobs simultaneously), and I know a million ways that C++ features suck. Also standard library and containers. If you want I'll point out the ways in which std::deque, and even std::map, std::unordered_map, even std::vector (!) suck. IMO, just don't do it.

The standard library implements really do suck (in some cases), but this should be separated from C++ (the language). Even the standard splits the language grammar from the standard library cleanly.

You can't really separate the two, firstly because some parts of the standard library interact directly with the language's syntax (e.g. ), and secondly because the language standard dictates things about the behavior of the standard library that limit implementation options.

For example, the standard says that adding elements to an is not allowed to invalidate references to keys or elements within the map. That makes it impossible for any standards-compliant C++ implementation to use a high-performance implementation in which keys and elements are stored contiguously in a flat array.

Re: Orthodox C++ (2016)

#59

Post by nly »

cyber_kinetist wrote: post #32
rfgplk wrote: post #7

I've developed a style that I legitimately call Heterodox C++ (mainly due to the popularity of Orthodox C++), it is effectively a purely functional & metaprogramming heavy style of C++. Quite the opposite of this, not everyones cup of tea, and it won't fit into every codebase but it is incredibly powerful. The template metaprogramming C++ offers is the most powerful of any imperative language, and (subjective opinion…

The problem with metaprogramming-heavy C++ codebases is always compilation times and obtuse error messages... Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.

> obtuse error messages

With concepts and constexpr-if and consteval it's increasingly less of a problem

Re: Orthodox C++ (2016)

#60

Post by pjmlp »

rfgplk wrote: post #16

This is gonna be a long critique, I'll try to keep it concise. > C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities. C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). The…

For me it was already obsolete in 1992, when I was given a copy of Turbo C++ 1.0 for MS-DOS.

It was the next step from Turbo Pascal in terms of safety, with added benefits from cross platform.

Nowadays all C compilers that matter are written in C++ anyway.

Post reply on HN