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

91–100 of 395 posts

Re: Modern C++ Won't Save Us

#91

Post by hak8or »

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…

Can you or others post such alternative standard libraries? The only ones that come to mind are boost (which is a nightmarefor compile times and I feel is a mishmash of old and new) and googles absiel which I haven't actually tried enough to make an opinion about.

Re: Modern C++ Won't Save Us

#92

Post by School-Cotton »

MiroF wrote: post #59

The stringview example is surprising and certainly something I could have fallen for. I feel like the lambda example is pretty contrived. If I was returning a lambda that was capturing values by reference, I would already be pretty wary of UB.

I guess it comes down to the individual reader. I had to look at the lambda example several times to realize what the problem was with it. I guess my eyes just skim over the capture section unless I have some good reason to look at it. The string_view example, on the other hand, was immediately obviously wrong to me.

Re: Modern C++ Won't Save Us

#93

Post by Animats »

The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks.

string_view is really a non-mutable borrow. But the compiler does not know this.

Re: Modern C++ Won't Save Us

#94

Post by AnimalMuppet »

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.

Been there, done that. We were using Pascal (standard Pascal, no Turbo extensions) on a machine with memory mapped I/O. This means that we had to drop into assembly to write to the I/O registers. And that meant that we lost all type checking for those functions. We couldn't even check the number of parameters! Unsurprisingly, that led to a crash.

That is: The extreme safety of Pascal led to a crash (when we had to do something that Pascal, in its wisdom, said we weren't allowed to do).

Re: Modern C++ Won't Save Us

#95

Post by colanderman »

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…

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr).

The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), but I think this is a conscious decision (and IMO the correct decision) to include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics. There's rhyme and reason to most of the most commonly used elements that is decidedly lacking from e.g. Python's (much more extensive) standard library.

Re: Modern C++ Won't Save Us

#96

Post by AnimalMuppet »

leshow wrote: post #84
AnimalMuppet wrote: post #80

Earlier quoted context omitted.

Well, it shows that there are aspects of C/C++ which are unsafe. But you don't have to use string_view or span, you know...

It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.

Fair enough. But tatersolid seems to be condemning the entire language, which is a step too far for the evidence given.

Re: Modern C++ Won't Save Us

#97

Post by 4thaccount »

ajross wrote: post #64
arcticbull wrote: post #63

Earlier quoted context omitted.

It’s definitely easier to reason about than C++ because it errs on the side of safety and explicitness. You can use things you don’t understand without fear which straddles the boundary in a good way IMO. To your point that doesn’t make it simple. As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wron…

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

"Rust is the new APL,like I said"

I know you're trying to compare it to APL as that language mostly died off and is thus obscure, but I think the analogy is a little off.

While APL is weird, it is actually really easy for me (someone with less than 15 hours playing with the language in total over the past few years) to code up some basic scripts a lot easier than something like C++.

I'm being absolutely serious too. C++ is pretty low level and as a Python coder I feel like I'm sinking in quicksand with everything required to do something simple. APL is basically built around passing arrays of numbers or strings to weird symbols that operate on the whole array. This means I can do text processing with only a few symbols and a library function (and all interactively) where C++ requires lots of boilerplate and debuggers and compilation and pointers. In short, APL seems to be a lot less complicated than both Rust and C++ in my opinion and most using it have very little formal programming experience and have no problem picking it up from what I've read.

I know what you were essentially trying to say though.

Re: Modern C++ Won't Save Us

#98

Post by millstone »

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 agree with this and would take it a step further, and say that recent changes to the STL are the worst parts of modern C++. For example std::regex supports 6 distinct syntaxes, the PRNG stuff is massively over-engineered, the "extensions for parallelism" add complexity without giving enough knobs for any real perf improvement. Meanwhile there's gaping holes like UTF-8 support. It's a sad state.

Re: Modern C++ Won't Save Us

#100

Post by mjevans »

School-Cotton wrote: post #85
mjevans wrote: post #65

Earlier quoted context omitted.

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

The problem, as far as I understand it (though I’m a layman), is that by the time the dead code optimization pass runs, the code has been transformed so much that there’s no obvious way for the compiler to tell the difference between “obvious programmer-intended null check that we shouldn’t optimize out” and “spurious dead code introduced by macro expansion” or (in C++) “by template instantiation”.

Couldn't user defined branches be tagged by such a compiler and if a tagged branch is eliminated the error generated with a reference to the tagged line in question?
Post reply on HN