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

71–80 of 238 posts

Re: Orthodox C++ (2016)

#71

Post by tialaramex »

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…

> nearly 99% of the C standard is in C++

But, one of the annoying habits of WG21 (the C++ committee) is sending stuff to WG14 (the C committee) to have them make it part of their language rather than accept that it's a C++ problem. Even the stupid type qualifiers are actually C++'s fault, K&R doesn't have this abomination but the pre-standard C++ did so too bad now it's in C89.

Re: Orthodox C++ (2016)

#72

Post by tialaramex »

rfgplk wrote: post #49
IncreasePosts wrote: post #24

Earlier quoted context omitted.

If we accept the maximum that "any sufficiently advanced technology is indistinguishable from magic", then c++ is indeed magic. It's so advanced that one of the worlds foremost experts in the language(herb sutter) has determined that the language is too complex and we need a whole new language(confront) which is simpler and can be converted to c++.

C++ is actually obscenely complex, I don't deny that. Just mastering object lifetime rules is crazy difficult due to all the edge cases, but it comes with the territory.

> it comes with the territory

In the sense that C++ is complicated because it's C++, which is complicated? That's just a tautology. If you mean "the territory" in some other sense there's no reason to believe this.

Re: Orthodox C++ (2016)

#73

Post by flohofwoe »

rfgplk wrote: post #8
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.

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…

> Malloc and memory allocation methods are at least 10k+ lines of code for instance.

Only the really big ones, e.g. here is Emscripten's allocator that focuses on small binary size and is implemented in about 1.5 kloc (ignoring comments and whitespace it's actually under 1 kloc), and that allocator is perfectly fine for most use cases (especially C code bases which typically don't have a high allocation frequency):

https://github.com/emscripten-core/emscripten/blob/main/syst...

...and Seb Aaltonen's offset allocator (used for allocating GPU buffers in his Vulkan API wrapper) has under 500 lines of code:

https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAl...

Right tool for the job etc... big general-purpose allocators like jemalloc or mimalloc are usually a bandaid to somewhat salvage a failed memory management strategy.

Re: Orthodox C++ (2016)

#74

Post by Chaosvex »

rfgplk wrote: post #8
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.

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…

[dead]

Re: Orthodox C++ (2016)

#75

Post by nly »

wavemode wrote: post #58
rfgplk wrote: post #45

Earlier quoted context omitted.

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

Your map example only concerns the standard library, not the language.

Re: Orthodox C++ (2016)

#76

Post by wglb »

kabdib wrote: post #62
wglb wrote: post #52

Earlier quoted context omitted.

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.

I have seen a pure C/C++ implementation of coroutines (it used setjmp/longjmp, and memcpy to copy stacks in and out of the native arena). Not the most portable of constructions, but it worked absurdly well. Being able to write "async" code essentially in-line is a superpower.

Agree but nowhere as easy as what we did https://ciex-software.com/coroutines.html

Re: Orthodox C++ (2016)

#77

Post by EPWN3D »

rfgplk wrote: post #8
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.

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…

C programmers aren't complaining about the "magic" being tens of thousands of lines of code. They're complaining about the magic including bizarre side effects that brazenly violate the principle of least astonishment.

In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator.

I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.

Re: Orthodox C++ (2016)

#78

Post by lelele »

pjmlp wrote: post #50
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.

Just like any C function without looking into the translation unit, don't say you blindly believe on the function name.

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 times. I could finally program without the constant mental overhead of watching out for C++ pitfalls.

Re: Orthodox C++ (2016)

#79

Post by lelele »

LoganDark wrote: post #41
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.

> C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb. You can't take C code at face value either. The name of a method or type doesn't tell you what it does. It could longjmp for all you know.

See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416

Re: Orthodox C++ (2016)

#80

Post by lelele »

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?

See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416
Post reply on HN