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

281–290 of 334 posts

Re: C++: The Documentary

#281

Post by zeroc8 »

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…

The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.

Re: C++: The Documentary

#282

Post by spacechild1 »

coffeeaddict1 wrote: post #253

An interesting opinion on this by Chandler Carruth: https://hachyderm.io/@chandlerc/116694268329657881 .

He has a point. The video certainly feels more like a hagiography and I noticed the lack of critical voices. Only in the last 10 minutes they touched on some common criticisms, like the growing complexity and the memory safety issues. I still enjoyed it, though.

Re: C++: The Documentary

#283

Post by nemetroid »

einpoklum wrote: post #118
afdbcreid wrote: post #109

Earlier quoted context omitted.

What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.

Oh, on the contrary, the separate structure is needed and useful because it offers _less_, not more: * APIs/function signatures explain more clearly what are the intended uses of the structure that's passed. * More potential for compiler optimization * Some potential for having these on the stack (if the compiler deduces the size already at compile-time) * More convenient for static analysis * No plethora of confusin…

How are any of these achieved by a vector-like type with capacity frozen at construction time?

Re: C++: The Documentary

#284

Post by quuxplusone »

afdbcreid wrote: post #109
einpoklum wrote: post #99

Earlier quoted context omitted.

> There's a single "I guess I would use this" container type, std::vector. About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy. Agree with your takes on most of the c…

What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.

The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.

But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.

Re: C++: The Documentary

#285

Post by kibwen »

frollogaston wrote: post #269
kibwen wrote: post #140

Earlier quoted context omitted.

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.

The notion of Turing completeness isn't relevant here, it encompasses almost none of the interesting distinctions between programming languages in practice. And yes, simplicity alone isn't what matters here, or else we'd all be applauding Brainfuck. What matters is strength:weight ratio, or the interesting expressiveness and abstractive power of your language weighed against its surface area.

Re: C++: The Documentary

#286

Post by xonre »

tralarpa wrote: post #175
maccard wrote: post #38

Earlier quoted context omitted.

This is true of any language. Python with flask vs django, with/without type hints. JavaScript with anhular and vue. The varying standards are no different to major python versions or go versions - arguably there’s even less between most versions than there is in your average go release. The differences in apps and frameworks don’t matter for day to day - std::string, Unreal’s FString and QT’s QString all are similar…

> This is true of any language Is it? Java has changed a lot, but in such a way that it's still easy to mentally map new features to the old ones, provided you have understood the core language. IDEs can even convert your code from old to new and back.

Still true for C++. Can still mentally map new features to the core language C. A modern Cfront transpiler can still be written.

Template meta-programming maps to C pre-processor macros. The sad part with both is generated code cannot be examined thus the unreadable compiler errors and slower compilation as it's regenerated every time.

Slightly off-topic: Rust can also be mentally mapped to C.

Re: C++: The Documentary

#287

Post by markus_zhang »

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

Can you please share an example of the precise mental model of something?

Re: C++: The Documentary

#288

Post by steveklabnik »

bregma wrote: post #259
kllrnohj wrote: post #187

Earlier quoted context omitted.

> I really recommend against using C++ for safety-certified embedded software. Stick to C. You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.

Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use. Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.

Rust has multiple qualified compilers for several safety standards, with more in progress.

Re: C++: The Documentary

#289

Post by Brian_K_White »

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 don't find programming with C++ that hard."

That's the easy half.

The old joke used to be that perl is a write-only language. Hell the way I write bash is pretty write-only (basically golf). I'd say so is C++.

A lot of things are easy to write and then impossible to read or develop.

Re: C++: The Documentary

#290

Post by Brian_K_White »

ivanjermakov wrote: post #227
TonyAlicea10 wrote: post #122

I always tell web developers I teach that the language of the internet isn’t JavaScript it’s C++. Web devs are just users playing in a C++ dev’s program. ;)

Continuing the analogy, browser devs are just users playing in C/OS/kernel program.

That doesn't actually follow.

A C++ compiler outputs machine code that runs on a raw cpu if you want it to. The os providing a virtual cpu is just an optional extra and so irrelevant.

That is not true for someone writing php or js or anything that runs in an interpreter. C/OS/Kernel are not actually the interpreter for C++, or they are, but only in the same way that the bare hardware is. C++ is the final interpeter layer besides assembly.

Post reply on HN