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

Rethinking C++: Architecture, Concepts, and Responsibility

blogs.embarcadero.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#41

Post by surajrmal »

instig007 wrote: post #36
simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

> The range of problems where C++ is unequivocally the superior solution is getting smaller. The range of issues where the superior solutions offer language features superior to the features of modern C++ is getting smaller too.

The c++ features that get bolted on to replicate those in other languages tend to never reach parity because of all the legacy baggage they need to design around. Modules are not nearly as useful as one would hope. std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents. coroutines are not exactly what anyone really wanted. If you're simply looking for checkboxes on features then I suppose you have a point.

To be clear, I like and continue to use modern c++ daily, but I also use rust daily and you cannot really make a straight faced argument that c++ is catching up. I do think both languages offer a lot that higher languages like go and Python don't offer which is why I never venture into those languages, regardless of performance needs.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#42

Post by amluto »

simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

The author seems to be writing about a dream language that isn’t actually C++. For example:

> In my streams I showed how RAII can thereby also be applied to database operations: a connection exists as long as it is in scope.

Only if that connection object doesn’t support move — we’re 12 years of C++ standards past the arrival of move, and it still leaves its source in an indeterminate state.

> With std::variant, C++ gained a tool that allows dynamic states without giving up type safety.

variant is not quite type-safe:

https://en.cppreference.com/w/cpp/utility/variant/valueless_...

> With C++20, std::ranges decisively extends this principle: it integrates the notions of iterator, container, and algorithm into a unified model that combines type safety and readability.

Ranges may be type-safe, but they’re not safe. Like string_view, a range is a reference, and the language does not help ensure that the referent remains valid.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#43

Post by ahartmetz »

yosefk wrote: post #5

"Many—especially historically minded—developers complain that modern C++ compilers take longer to compile. But this criticism is short‑sighted. You cannot compare C++ compile times with compilation in other languages, because the compiler is doing something entirely different."

I wonder if it's time to implement some library features in the compiler. Some things are very widely used and very rarely modified. It should be possible to opt out and use the library version, of course.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#44

Post by surajrmal »

jandrewrogers wrote: post #12
fsloth wrote: post #3

I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable. C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization). C++ is valuable becaus it's industry support guarantees code bases live for decades _without…

C++20 inverts the traditional relationship between the core language and metaprogramming, which arguably makes it new language in some ways. Instead of being a quirky afterthought, it has become the preferred way to interact with code. There is a point of friction in that the standard library doesn’t (and can’t) fully reflect this change. Metaprogramming style in C++20 only has a loose relationship to previous versio…

Wait until people see how reflection on c++26 further pushes the metaprogramming paradigm. I'm more hopeful for reflection than I have been for any other c++ feature which has landed in the last decade (concepts, modules, coroutines, etc).

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#45

Post by recursivecaveat »

It's okay to admit when C++ doesn't have a feature. std::variant is an approximation of sum type support. It's ergonomics are an absolute travesty as a result, any errors you get are going to be 5 pages of template gunk, and I'm sure that using it pervasively is terrible for compile times. It has been possible to construct a type safe unit library as demonstrated in the article for forever. I've never seen anyone use this ability in a production codebase, because a terrible library emulation of a feature is not a real feature.

The notion that just using the new fancy types automatically makes everything memory safe has to stop. std::expected contains either a value or an error. If you call .value() and you're wrong you get an exception. If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. Since there's no destructuring you have to call these methods btw, just don't make any mistakes with your preconditions! Regardless 90% of memory safety errors I see are temporal. Unless we completely ban references and iterators they will not be going anywhere. Using unique_ptr instead of new does not do anything when you insert into a map while holding a reference to an element.

Developers also have to be able to make their own things. We can't pretend that absolutely everything we will ever need is bundled up in some perfect library. To write a typesafe application you need to be able to create your own domain specific abstractions, which to me precludes them looking like this:

    template 
    concept db_result_tuple = requires { typename remove_cvref_t; }
                           && [](std::tuple*) {
                                return all_result_args_ok_v;
      }( static_cast>>(nullptr) );

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#46

Post by surajrmal »

jstimpfle wrote: post #10
gpderetta wrote: post #4

Earlier quoted context omitted.

sorry, I can't take something that argues for "printf" in favour of anything else seriously.

I'll bite. printf might be unsafe in terms of typing, in theory, but it's explicit and readable (with some caveats such as "PRIi32"). The actual chance of errors happening is very low in practice, because format strings are static in all practical (sane) uses so testing a single codepath will usually detect any programmer errors -- which are already very rare with some practice. On top of that, most compilers validat…

I largely avoided iostream in favor of printf-like logging apis, but std::format changed my mind. The only hazard I've found with it is what happens when you statically link the std library. It brings in a lot of currency and localization nonsense and bloats the binary. I'm hoping for a compiler switch to fix that in the future. libfmt, which std::format is based on, doesn't have this problem.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#47

Post by wavemode »

simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

> decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software

How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011?

If you've worked on a project built entirely on the technologies and principles of modern C++, and found that it caused your software to be low-quality, then by all means share those experiences. C++ has no shortage of problems, there is no doubt. But hand-waving about "decades" of nondescript problems other people have had with older C++ versions, is somewhat of a lazy dismissal of the article's central thesis.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#48

Post by instig007 »

surajrmal wrote: post #41
instig007 wrote: post #36

Earlier quoted context omitted.

> The range of problems where C++ is unequivocally the superior solution is getting smaller. The range of issues where the superior solutions offer language features superior to the features of modern C++ is getting smaller too.

The c++ features that get bolted on to replicate those in other languages tend to never reach parity because of all the legacy baggage they need to design around. Modules are not nearly as useful as one would hope. std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents. coroutines are not exactly what anyone really wanted. If you're simply looking for checkboxes on features then…

> std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents.

> but I also use rust daily and you cannot really make a straight faced argument that c++ is catching up.

I mostly use std::ranges, lambdas, and concepts, and I see them catching up, as an evolutionary process rather than a fixed implementation in the current standard. Nowadays I can do familiar folds and parallel traversals that I couldn't do in the past without assuming third-party libraries. My optionals are empty vectors: it suits my algorithms and interfaces a lot, and I never liked `Maybe a` anyways (`Either errorOrDefault a` is so much better). I also use Haskell a lot, and I'm used to the idea that outside of my functional garden the industry's support for unions is hardly different to the support of 2-tuples of (, ), so I don't mind the current state of std::variant either.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#49

Post by PaulDavisThe1st »

MontagFTB wrote: post #40
instig007 wrote: post #34

Earlier quoted context omitted.

> Once you get to that point, you might as well create and learn a different language. Nope, it's still incredibly valuable to be able to c++14 and c++26 two different translation units and then later link them together (all without leaving the familiar toolchains and ecosystems). That's how big legacy projects can evolve towards better safety incrementally.

If the Standard has anything to say about compatibility between different language versions, I doubt many developers know those details. This is breeding ground for ODR violations, as you’re likely using compilers with different output (as they are built in different eras of the language’s lifetime) especially at higher optimization settings. This flies in the face of modern principles like building all your C++, fro…

> Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design.

Historically, C++ compilers' name mangling scheme for symbols did precisely the same thing. The 2000-2008 period for gcc was particularly painful since the compiler developers really used it very frequently, to "prevent these kinds of issues by design". The only reason most C++ developers don't think about this much any more is that most C++ compilers haven't needed to change their demangling algorithm for a decade or more.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#50

Post by trzy »

I think they should chuck the STL and start over. I left C++ for a while and spent a lot of time in C# and Swift. Going back to C++ is painful because the interfaces feel very non-uniform and cumbersome.

I also think that named parameters would go a long way toward improving the language.

Lastly, explore some way to make possible a breaking change with "old C++".

Post reply on HN