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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

211–220 of 395 posts

Re: Modern C++ Won't Save Us

#211

Post by dagw »

arcticbull wrote: post #70
the_trapper wrote: post #46

Earlier quoted context omitted.

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

C++ has a huge learning curve too though, the difference is it lets you write whatever you want. The learning curve is to write correct C++. It’s deceptive, it’s like skiing vs snowboarding. Skiing you pick up fast but to get good is damn hard and few bother. Snowboarding is damn hard to pick up but then it’s pretty easy to become really good.

then it’s pretty easy to become really good.

To modify this I'd say that becoming reasonably good is pretty easy (and I'd agree easier than skiing). To be become really good takes a long time and a lot of dedication and the difference in difficulty between skiing and snowboarding disappears. Same as with programming, some languages make it easier to go from 0 to your first app, some make it easier to write solid production ready code that earns you a paycheck, but becoming really good is always hard and independent of the language you're using.

Re: Modern C++ Won't Save Us

#212

Post by noselasd »

masklinn wrote: post #197
jcelerier wrote: post #186

Earlier quoted context omitted.

> (namely that you can just deref' an std::optional and it's UB if the optional is empty). if that was not the case, `optional` would get exactly zero usage. The point of those features is that you build in debug mode or with whatever your standard library's debug macro is to fuzz your code, but then don't inflict branches on every dereference for the release mode.

> The point of those features is that you build in debug mode or with whatever your standard library's debug macro is to fuzz your code, but then don't inflict branches on every dereference for the release mode. That's completely insane. If there's always a value in your optional it has no reason to be an optional, if there may not be a value in your optional you must check for it.

Sure, but that's not the issue. You should be using a std::optional like e.g.

   if (my_optional) 
         do_stuff(*my_optional);
Here's one (explicit)conditional.

However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

Re: Modern C++ Won't Save Us

#213

Post by clouddrover »

hu3 wrote: post #194
clouddrover wrote: post #19

Earlier quoted context omitted.

Like this: https://rust-embedded.github.io/book/

That's not memory safe as the book itself states: > Now, the volatile accesses are performed automatically through the read and write methods. It's still unsafe to perform writes, but to be fair, hardware is a bunch of mutable state and there's no way for the compiler to know whether these writes are actually safe, so this is a good default position. https://github.com/rust-embedded/book/blob/9c05a419fc2ad231c...

I think you need to read on a bit further. The very next section after the sentence you quoted is:

"We need to wrap this struct up into a higher-layer API that is safe for our users to call. As the driver author, we manually verify the unsafe code is correct, and then present a safe API for our users so they don't have to worry about it (provided they trust us to get it right!)."

Rust lets you write clearly defined unsafe code blocks. It's not a bug, it's a feature:

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

https://doc.rust-lang.org/nomicon/index.html

It's worth reading through the whole Embedded Rust book even if you won't be implementing such software. It's interesting.

Re: Modern C++ Won't Save Us

#215

Post by madisfun »

petters wrote: post #145
blt wrote: post #127

Earlier quoted context omitted.

How is the prng over engineered? I agree its a little clunky for casual use but it makes all the right decisions, imo, for serious use of prngs (e.g. reproducible experiments for Monte Carlo methods in simulation and statistics)

Initializing the mersenne twister is really hard: https://github.com/PetterS/monolith/blob/master/minimum/core... Edit: There are two links in the code with more info.

Mersenne Twister has a huge state, and if you have to use the MT (you need a very long period), you will probably want to be able to initialize it properly. For the common use case is a linear congruential generator which is initialized with just one integer.

Re: Modern C++ Won't Save Us

#216

Post by snaky »

User23 wrote: post #35
tedunangst wrote: post #18

Earlier quoted context omitted.

By calling unsafe code. :) The semantics and guarantees offered by the interface vary, but that's the short version.

Often that unsafe code is assembly language.

Presuming it's not formally verified assembly code https://blogs.ncl.ac.uk/andreymokhov/spacecraft-control/

Re: Modern C++ Won't Save Us

#217

Post by kabdib »

jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

I work in a shop where there was a significant effort in a cross-platform library a long time ago, but that old code has been showing cracks and emitting creaks ("Hey, folks, guess how many debugging hours it took to find out that lambdas didn't work here, either"). Use of the standard library is frowned upon except when absolutely necessary, so there's no avoiding the thing. From time to time someone will joust at it and pull a particularly screwball section forward a decade or two, but on the whole the old stuff is just never going away short of a catastrophe. It makes onboarding interesting, and it makes you reflect philosophically on expertise that is valuable absolutely no place else.

I work on other projects, or on my own stuff at home, and I can breathe again. I don't always need reverse iterators on a deque, but dammit they are there if I need them.

However, I have been in too much C runtime code to be entirely happy. I've seen too many super-complicated disasters, for instance the someone who really wanted to write the Great American OS Kernel but who wasn't allowed on the team, and so had to make their bid for greatness in stdio.h instead. You learned to tread carefully in that stuff, the only good news being that if you broke something it might have turned out to be already busted anyway and no harm done, philosophically speaking, I mean.

There are no good answers :-)

Re: Modern C++ Won't Save Us

#218

Post by comex »

noselasd wrote: post #212
masklinn wrote: post #197

Earlier quoted context omitted.

> The point of those features is that you build in debug mode or with whatever your standard library's debug macro is to fuzz your code, but then don't inflict branches on every dereference for the release mode. That's completely insane. If there's always a value in your optional it has no reason to be an optional, if there may not be a value in your optional you must check for it.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

Nah. In simple cases like that, the compiler would always be able to optimize away an extra check, if such a check were present. After inlining operator bool and operator *, it would look something like

    if (my_optional->_has_value)
        if (my_optional->_has_value)
            do_stuff(my_optional->_value);
        else
            panic();
and the compiler knows that the second if statement will pass iff the first does.

On the other hand, if the test is further away from the dereference, and perhaps the optional is accessed through a pointer and the compiler can't prove it doesn't alias something else, it might not be able to optimize away the check. However, that probably doesn't account for too high a fraction of uses.

Re: Modern C++ Won't Save Us

#219

Post by ayosec »

noselasd wrote: post #212
masklinn wrote: post #197

Earlier quoted context omitted.

> The point of those features is that you build in debug mode or with whatever your standard library's debug macro is to fuzz your code, but then don't inflict branches on every dereference for the release mode. That's completely insane. If there's always a value in your optional it has no reason to be an optional, if there may not be a value in your optional you must check for it.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

How is that different to this?

    if (my_pointer != NULL)
        do_stuff(*my_pointer)

Re: Modern C++ Won't Save Us

#220

Post by fetbaffe »

vasilipupkin wrote: post #130
Tracist wrote: post #116

Earlier quoted context omitted.

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. The whole comment sounds so much like well written satire, but I think he's being serious.

I agree with him. in many practical applications with well design class hierarchies it just really isn't much of an issue. Hasn't been for me either.

> with well design class hierarchies

:eyes:

Post reply on HN