Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Not forever if this ever comes through,
That's the wrong direction. What's needed are intelligent converters which convert less-strict languages to more-strict ones.
Non-intelligent converters just make a mess. Here's c2rust.[1]
Classic C++ to modern C++, plus a compiler flag to lock out all the old unsafe stuff, would be an achievement.
StripAsciiWhitespace should take a string_view like here: https://github.com/abseil/abseil-cpp/blob/master/absl/string...
The UB comes from AsciiStrToUpper returning a new std::string which StripAsciiWhitespace takes as a string_view (implicit conversion). By the time you print foo2, the string is already freed.
> Google threw the weight of their top C++ engineers behind Carbon. It's happening.
Google throws their weight behind a lot of projects. You can find a list of 282 of those projects here: https://killedbygoogle.com/
It's very opinionated and SerenityOS-focused, but the language Jakt ( https://github.com/SerenityOS/jakt ) transpiles to C++, has memory safety and some very neat ideas for readability.
Not really, at least not during this decade.
> Note that we don't expect to finish the 0.1 language work in 2023. Our goal is to make sufficient progress that we can complete it in 2024, but there are still many things that can go wrong and cause significant delays.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
So while an interesting experiment, and it can even get an ecossytem of its own, provided it doesn't go out of steam, it is still quite far from that.
You'd think so, but C doesn't have the performance crown always either due to language design choices. A big one is aliasing (which languages like Rust and Fortran forbid) which inhibits the ability for very impactful and common low-level optimizations that come up all the time. Performance characteristic differences between C vs C++ are not all that interesting because the language models are so similar (& thus similarly the compilers for them basically have the same model). Indeed, higher level of abstractions can help improve performance as virtual classes will outperform manual attempts at doing similar things (due to devirtualization passes within the compiler). That's actually been a friction point for Rust using LLVM because LLVM is built around the C/C++ language model and it's hard to express certain invariants to it that would result in even more efficient code or you try to use optimization passes that turn out to be broken because they're not really used by the broader C/C++ community (https://github.com/rust-lang/rust/issues/54878).
Well, performance has been improved by several orders of magnitude since the first release. So maybe it's time to look at https://raku.org again (or first have a look at its new documentation site https://docs.raku.org)
Well, performance has been improved by several orders of magnitude since the first release. So maybe it's time to look at https://raku.org again (or first have a look at its new documentation site https://docs.raku.org)