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

51–60 of 80 posts

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

#51

Post by jnwatson »

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…

If you're going to go through the effort of learning a new language, it makes sense to consider another language altogether, one without 30 years of accumulated cruft.

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

#52

Post by MontagFTB »

PaulDavisThe1st wrote: post #49
MontagFTB wrote: post #40

Earlier quoted context omitted.

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 abo…

C++’s name mangling scheme handles some things like namespaces and overloading, but it does not account for other settings that can affect the ABI layer of the routine, like compile time switches or optimization level.

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

#53

Post by hsaliak »

When I got into computing, it was a refuge from societal expectations. Now you cannot code in whatever programming language because of societal expectations to do it safe, do it with modern libraries, with the right build system etc.. just do what you like. Its OK. Have fun.

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

#54

Post by pjmlp »

kaiken1987 wrote: post #35
pjmlp wrote: post #2

I still love C++ Builder, regardless of all Borland misteps that lead to where Embarcadero is today, it is the survivor of C++ RAD IDE tooling, Visual C++ never was as Visual as it name implies.

Builder and Delphi 6 had a way to build and design UI's that worked smoothly that I've yet to see from a UI framework.

Indeed, pity that they are only available to those of us that don't mind using the community editions, or work at companies that usually don't care that much about commercial licenses prices, meaning project delivery costs is measured in millions.

Sure there is FreePascal and Lazarus, sadly it doesn't get enough love.

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

#55

Post by nurettin »

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…

Isn't it a "skill issue" whenever you complain about a language? I can say rust is too slow and too convoluted, and you will tell me "well stop fsckin cloning everything and use Arc everywhere. Oh and yeah lifetimes are hard but once you get used to it you will write perfect programs like my claude max subscription does!"

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

#56

Post by jandrewrogers »

jebarker wrote: post #24
jandrewrogers wrote: post #12

Earlier quoted context omitted.

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…

As someone that has only dabbled in C++ over the past 10 years or so, it feels like each new release has this messaging of “you have to think of it as a totally new language”. It makes C++ very unapproachable.

It isn’t each release but there are three distinct “generations” of C++ spanning several decades where the style of idiomatic code fundamentally changed to qualitatively improve expressiveness and safety. You have legacy, modern (starting with C++11), and then whatever C++20 is (postmodern?).

This is happening to many older languages because modern software has more intrinsic complexity and requires more rigor than when those languages were first designed. The languages need to evolve to effectively address those needs or they risk being replaced by languages that do.

I’ve been writing roughly the same type of software for decades. What would have been considered state-of-the-art in the 1990s would be a trivial toy implementation today. The languages have to keep pace with the increasing expectations for software to make it easier to deliver reliably.

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

#57

Post by ActorNightly »

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…

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

Unreal Engine is C++ based and plenty of games have used it.

Fundamentally, when it comes to safety, its either everything or nothing. Rust is by definition unsafe, because it has "unsafe" keyword. If the programmer has enough discipline not use use unsafe everywhere, he/she has enough discipline to write normal C++ code.

But as far as C++ goes, the main problem is that the syntax still allows C style pointers and de referencing for compatibility with C code. Generally, if you stick to using std library constructs and smart pointers for everything, the code becomes very clean. Unique ptr is basically the thing that inspired Rust ownership semantics after all.

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

#58

Post by TinkersW »

jstimpfle wrote: post #18
TinkersW wrote: post #14

Earlier quoted context omitted.

I my experience you absolutely must have type checking for anything that prints, because eventually some never previously triggered log/assertion statement is hit, attempts to print, and has an incorrect format string. I would not use iostreams, but neither would I use printf. At the very least if you can't use std::format, wrap your printf in a macro that parses the format string using a constexpr function, and veri…

_Any_ code that was never previously exercised could be wrong. printf() calls are typically typechecked. If you write wrappers you can also have the compiler type check them, at least with GCC. printf() code is quite low risk. That's not to say I've never passed the wrong arguments. It has happened, but a very low number of times. There is much more risky code. So such a strong "at the very least" is misapplied. All…

Error Log/assertions prints are by are the most likely code to have not been run prior. Some compilers type check printf, but not all.

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

#59

Post by PaulDavisThe1st »

MontagFTB wrote: post #52
PaulDavisThe1st wrote: post #49

Earlier quoted context omitted.

> 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 abo…

C++’s name mangling scheme handles some things like namespaces and overloading, but it does not account for other settings that can affect the ABI layer of the routine, like compile time switches or optimization level.

The name mangling scheme was changed to reflect things other than namespaces and overloading, it was modified to reflect fundamental compiler version incompatibilities (i.e. the ABI)

Optimization level should never cause link time or run time issues; if it does I'd consider that a compiler/linker bug, not an issue with the language.

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

#60

Post by ActorNightly »

dustfinger wrote: post #39

Despite all the critisism, C++ has been my favorite language for 20+ years. Nowadays I code 99% of the time in python and previously TypeScript, but all my personal for fun projects are in C++. I just enjoy coding in it so much more. I know I will get some heat for this, but I would love to live in an idealistic world where computers were still for hackers and it was all just about fun not profit. I was so inspired b…

> but I would love to live in an idealistic world where computers were still for hackers

This never changed.

In the past, hacking was exploiting human errors in writing faulty code. These days, its pretty much the same thing except the faulty code isn't things like buffer overflows due to no bounds checking, but more higher level faulty software with things like password reuse, no 2 factor authentication, and so on.

Post reply on HN