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

31–40 of 80 posts

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

#31

Post by gwbas1c »

> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means.

> But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because through evolution it has become a different language. Only those who understand the modern language constructs can use the new tools properly and unfold the potential of this generation of libraries.

Once you get to that point, you might as well create and learn a different language.

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

#32

Post by TYPE_FASTER »

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…

> Metaprogramming style in C++20 only has a loose relationship to previous versions. It is now concise and highly maintainable. You can do metaprogramming in the old painful and verbose way and it will work but you can largely dispense with that.

This was my takeaway as well when I revisited it a few years ago. It's a very different, and IMO vastly improved, language compared to when I first used it decades ago.

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

#33

Post by pjmlp »

AnimalMuppet wrote: post #28
pjmlp wrote: post #15

Earlier quoted context omitted.

As someone that had the option to choose between C and C++, coming from compiled BASIC and Object Pascal backgrounds, back in the early 1990's. What makes C++ valueable is being a TypeScript for C, born in the same UNIX and Bell Labs farm (so to speak), allowing me to tap into the same ecosystem, while allowing me to enjoy the high level abstractions of programming languages like Smalltalk, Lisp, or even Haskell. Thu…

Does go count as managed, in your view? (Honest question - I don't know go well enough to have much of an opinion.)

Yes, managed languages are all that have some form of automatic resource management, regardless of what shape it takes, or a more high language runtime.

Using Go as example, and the being in minority remark, you will remember the whole discussion about Go being a systems language or not, and how it was backpedaled to mean distributed systems, not low level OS systems programming.

Now, I remember when programming compilers, linkers, OS daemons/services, IoT devices, firmware was considered actual systems programming.

But since Go isn't bootstraped, TinyGo and TamaGo don't exist, that naturally isn't possible. /s

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

#34

Post by instig007 »

gwbas1c wrote: post #31

> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means. > But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because th…

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

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

#35

Post by kaiken1987 »

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.

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

#36

Post by instig007 »

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.

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

#37

Post by simonask »

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.

There’s definitely holes, but I’m wondering what you are referring to here.

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

#39

Post by dustfinger »

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 by the writings of Eric S. Raymond, I always hoped I would experience some of that. ~SIGH~. Maybe in my retirement.

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

#40

Post by MontagFTB »

instig007 wrote: post #34
gwbas1c wrote: post #31

> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means. > But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because th…

> 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++, from source, at the same time, with the same settings.

Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design. Unless your whole team is a moderate-level language lawyer, you must enforce this by some other means or risk some really gnarly issues.

Post reply on HN