Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: The Documentary

herbsutter.com

Post reply on HN
Print view View original

261–270 of 334 posts

Re: C++: The Documentary

#261

Post by minipci1321 »

rustyhancock wrote: post #91
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I agree. You don't learn or know C++ in the way you learn or know C. You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across. The way I think of it C is an abstraction of the machine, so thin it's nearly transparent. C++ is an abstraction over programming paradigms, letting you pick how you think. Everything else abstracts the machine away, replacing it…

> C is an abstraction of the machine, so thin it's nearly transparent.

-Werror might help with that

Re: C++: The Documentary

#262

Post by jltsiren »

tialaramex wrote: post #194
patrick451 wrote: post #159

Earlier quoted context omitted.

> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.

> Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct,…

And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.

I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.

My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.

Re: C++: The Documentary

#263

Post by uecker »

bregma wrote: post #142
pjmlp wrote: post #72

Earlier quoted context omitted.

Not really, despite all its warts, it is exactly because of them that many reach out to C++. Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks. The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C a…

I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years. Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certif…

I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.

Re: C++: The Documentary

#264

Post by xedrac »

jmalicki wrote: post #204
72deluxe wrote: post #156

Earlier quoted context omitted.

But C++98 is so different to even C++11. Bjarne's book covering C++11 read completely differently to the 98 version, I found.

That just adds to the incoherency. It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too. C++ is this weird amalgam of like 7 different generations of languages. But by far the worst part is the developer hostility behind the…

I built my career on C++ and I agree with you. Rust is just superior in almost every way. C++ is dead to me for new projects.

Re: C++: The Documentary

#265

Post by xedrac »

bayindirh wrote: post #13
jdw64 wrote: post #11

It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I have felt this many times. However, the effort involved in writing code does not indicate the amount of issues that code may have. This is why I prefer Rust to C++ these days - it just removes 90% of the development tail, which can be quite long in C++.

Re: C++: The Documentary

#268

Post by WalterBright »

mirmor23 wrote: post #144

Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…

Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him:

1. do I need a license to create a C++ compiler?

2. do I need to call it something other than C++?

He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to ask permission.

I read about his passing a few years ago. He was a solid guy.

Re: C++: The Documentary

#269

Post by frollogaston »

kibwen wrote: post #140
GodelNumbering wrote: post #89

Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still

An elegant language is one that achieves a lot with very little. Forth and Scheme are elegant languages. You're free to like working in C++, and you can sure achieve a lot with it, but I don't think it's controversial to say that it does not do so with very little.

It's easy to make a minimal language that can technically do everything via Turing completeness. That can look elegant until you start writing reptitive or hard to read code with it. Golang "if err" is a classic.

Re: C++: The Documentary

#270

Post by bayindirh »

xedrac wrote: post #265
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I have felt this many times. However, the effort involved in writing code does not indicate the amount of issues that code may have. This is why I prefer Rust to C++ these days - it just removes 90% of the development tail, which can be quite long in C++.

That’s true, however I tend to build my testing harnesses alongside the code I write, hence every single function and the whole flow has a testing suite ready almost immediately (via Catch2 99%of the time), and every commit is tested locally and by a couple of runners after the commit.

This coupled with generous amount of Valgrind testing allows me to catch problems early and fix them immediately. Doing this allowed me to write very performant code without any leaks or accuracy problems.

Another thing I do is making some cases mathematically impossible. If this promise is broken, code is guaranteed to crash at that point, so it’s self verifying in a sense.

Of course enforcement of this is possible due to fact that I code solo most of the time, and has the discipline to do boring things as well as the exciting and fun things.

Post reply on HN