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

151–160 of 395 posts

Re: Modern C++ Won't Save Us

#151

Post by geezerjay »

usrnm wrote: post #131
mempko wrote: post #118

Earlier quoted context omitted.

C++ is designed for people to make nice libraries. Unlike other languages there is nothing special about the standard library (no magic language hacks). All libraries are first class citizens by design.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

You've cherry-picked a type trait as your example, which arguably could be a core language feature made to look like a third-party module.

Meanwhile, do you believe it's hard to implement a container?

And no, adding cruft to the STL is not a one-way street. See for example the history of C++'s smart pointers.

Re: Modern C++ Won't Save Us

#153

Post by geezerjay »

hak8or wrote: post #91
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.

> Can you or others post such alternative standard libraries?

POCO comes to mind.

https://pocoproject.org/

Re: Modern C++ Won't Save Us

#154

Post by ajxs »

ncmncm wrote: post #125
nradov wrote: post #108

Earlier quoted context omitted.

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

The Ada partisans are all out in force here in this thread to defend Ada, all four of us. haha... For what it's worth, niche as Ada may be, it's an _important_ niche. It remains widespread in safety-critical applications, and isn't going anywhere anytime soon. It's really good to see Rust taking lessons from Ada/SPARK in the area of formal proofing! If any language is going to threaten C++, it looks like Rust. I don't expect an Ada resurgence to happen, unfortunately.

> I cannot imagine a serious programmer switching from C++ to Go. If you can, you have a much livelier imaginary life than I do.

This got a laugh out of me.

Re: Modern C++ Won't Save Us

#155

Post by pjmlp »

nradov wrote: post #108
fooker wrote: post #103

Earlier quoted context omitted.

I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

Lack of tooling for HPC, GPGPU, mixed language graphical debugging across Java and .NET, native support for COM/UWP, game engines like Unreal, CryEngine and Unity.

Re: Modern C++ Won't Save Us

#156

Post by dearrifling »

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.

One shouldn't std::move in a return. Returning a local is already automatically an rvalue, however explicitly moving it disables copy elision.

Re: Modern C++ Won't Save Us

#157

Post by Razengan »

fooker wrote: post #103
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 don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).

What are the hidden language hacks in Swift?

Re: Modern C++ Won't Save Us

#158

Post by pjmlp »

ajxs wrote: post #154
ncmncm wrote: post #125

Earlier quoted context omitted.

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

The Ada partisans are all out in force here in this thread to defend Ada, all four of us. haha... For what it's worth, niche as Ada may be, it's an _important_ niche. It remains widespread in safety-critical applications, and isn't going anywhere anytime soon. It's really good to see Rust taking lessons from Ada/SPARK in the area of formal proofing! If any language is going to threaten C++, it looks like Rust. I don'…

A large majority of Ada partisans found their corner in Java, C# and C++'s type system improvements over C, and made the best we could from the sour grapes of C's copy-paste compatibility.

Re: Modern C++ Won't Save Us

#159

Post by masklinn »

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…

> 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.

Not to mention C++ does not really provide the facilities necessary for convenient, memory-safe and fast APIs[0].

And as demonstrated by e.g. std::optional the standard will simply offer an API which is convenient, fast and unsafe (namely that you can just deref' an std::optional and it's UB if the optional is empty).

[0] I guess using lambdas hell of a lot more would be an option but that doesn't seem like the committee's style so far.

Re: Modern C++ Won't Save Us

#160

Post by pjmlp »

Animats wrote: post #93

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.

Not quite true, Google and Microsoft are precisely adding a borrow checker to their static analysis tools.

https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...

Post reply on HN