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

311–320 of 334 posts

Re: C++: The Documentary

#311

Post by maccard »

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.

Yeah it is! Java 25 changed constructor behaviour to allow logic to run before the calls to super(). That’s an enormous change.

On the c++ side, “modern” features like span, smart pointers, range based for loops, format are all really simple to reason back to for anyone who is a programmer. Stuff like modules and concepts is a bit different, but most people aren’t in the innards of those every day, in the same way that the change in header size doesn’t affect every single Java developers code, but you should know about it.

Re: C++: The Documentary

#312

Post by 0xpgm »

doug_durham wrote: post #274
igouy wrote: post #246

Earlier quoted context omitted.

Which new languages have risen to prominence outside of a niche?

Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.

These became popular after Moore's law made it possible many years after C/Unix had become the standard.

And they became just good enough that more people didn't go into Lisp/Smalltalk instead.

Re: C++: The Documentary

#313

Post by ivanjermakov »

Brian_K_White wrote: post #290
ivanjermakov wrote: post #227

Earlier quoted context omitted.

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

Machine code is interpreted by CPU's microcode.

Re: C++: The Documentary

#314

Post by tialaramex »

bregma wrote: post #258
tialaramex wrote: post #194

Earlier quoted context omitted.

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

So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first? The problem does not appear to be in C++.

No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century.

The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority.

It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material.

† For cash, I don't like to owe people money, including having a mortgage

Re: C++: The Documentary

#315

Post by pjmlp »

maccard wrote: post #309
pjmlp wrote: post #182

Earlier quoted context omitted.

People using Visual C++ with MSBuild, or clang with CMake and ninja.

It’s been 6 months but last time I checked neither IntelliSense nor clangd worked with modules. The build tools have been just about functional for a while though, you’re right.

Yeah, Intelisense is a bummer, but you really need VS proper, nor VSCode, which I assume given the clangd reference.

Whereas one kind of works (VS), there is apparently no work going on VSCode Intelisense, ticket is stalled since January, and the promised announcement never came up.

Re: C++: The Documentary

#316

Post by bluGill »

flohofwoe wrote: post #308
bluGill wrote: post #255

Earlier quoted context omitted.

You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check

Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game. The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to f…

Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'

And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.

Re: C++: The Documentary

#317

Post by tialaramex »

ahartmetz wrote: post #129
tialaramex wrote: post #94

Earlier quoted context omitted.

So, a few things (aside from the whole nomenclature argument already in another reply) 1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea. 2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++)…

AFAIK, std::map is also OK for what it is: an ordered, node-based (tree) map. These are (almost) always slower than hash tables. Of course, std::unordered_map, the std hash table, sucks because of unforced errors. For that, there is boost::unordered_flat_map.

std::map will be a Red Black Tree, as with most of the other container types this really likes pointer chasing

Unlike in std::unordered_map you are getting some value here, the RB tree is able to achieve meaningful efficiency gains from its use of pointers. The trouble is that your computer isn't a PDP-11, a hybrid which does fewer dereferences but has more locality will trade well here on a real computer built this century.

So, I'm torn, it's not awful but it's a problem that std::map is basically obliged to be a Red Black Tree even though that's not a good fit for today's machines.

Re: C++: The Documentary

#318

Post by TonyAlicea10 »

ahartmetz wrote: post #307
TonyAlicea10 wrote: post #151

Earlier quoted context omitted.

Many browser rendering engines are built in C++, so C++ is parsing the HTML. My general point is that many web/internet techs that web devs interact with have C++ one abstraction level below for actual implementation.

All widely used HTML engines are C++. Of the up and coming ones, Servo is Rust and Ladybird is C++ potentially moving to Rust. In any case, Rust is basically C++ 2.0 to me because it is very much in the spirit of C++.

Yes I said “many” because if I didn’t qualify it someone would mention Rust.

Re: C++: The Documentary

#320

Post by einpoklum »

SJC_Hacker wrote: post #300
einpoklum wrote: post #141

Earlier quoted context omitted.

std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)

You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations. If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake

> As long as you don’t push_back

But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.

> If you want to get f cy you can also give it a custam allocator

And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.

Post reply on HN