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

21st Century C++

cacm.acm.org

Post reply on HN
Print view View original

121–130 of 281 posts

Re: 21st Century C++

#121

Post by musicale »

midnightclubbed wrote: post #111
erwincoumans wrote: post #105

Earlier quoted context omitted.

Same here. >>contemporary C++30 can express the ideas embodied in such old-style code far simpler IMO, newer C++ versions are becoming more complex (too many ways to do the same thing), less readable (prefer explicit types over 'auto', unless unavoidable) and harder to analyse performance and memory implications (hard to even track down what is happening under the hood). I wish the C++ language and standard library w…

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default. Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some…

I just wish they hadn't repurposed the old "auto" keyword from C and had used a new keyword like "var" or "let".

   #define var auto
   #define let auto

Re: 21st Century C++

#122

Post by musicale »

codr7 wrote: post #97
imron wrote: post #94

I want to love C++. Over my career I’ve written hundreds of thousands of lines of it. But keeping up with it is time consuming and more and more I find myself reaching for other languages.

I've been writing C++ since 1996-ish. Less and less, for sure. Nothing the past few years. They killed it.

Took me a moment to realize that "killed it" was being used in the negative sense.

Re: 21st Century C++

#123

Post by pro14 »

mindcrime wrote: post #109

I was an extreme C++ bigot back in the late 90's, early 2000's. My license plate back then was CPPHACKR[1]. But industry trends and other things took my career in the direction of favoring Java, and I've spent most of the last 20+ years thinking of myself as mainly a "Java guy". But I keep buying new C++ books and I always install the C++ tooling on any new box I build. I tell myself that "one day" I'm going to inves…

what is the job market like now for C++ programmers? I'm looking for a job.

Re: 21st Century C++

#125

Post by [deleted] »

musicale wrote: post #121
midnightclubbed wrote: post #111

Earlier quoted context omitted.

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default. Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some…

I just wish they hadn't repurposed the old "auto" keyword from C and had used a new keyword like "var" or "let". #define var auto #define let auto

[deleted]

Re: 21st Century C++

#126

Post by 3vidence »

mr_00ff00 wrote: post #108
codr7 wrote: post #97

Earlier quoted context omitted.

I've been writing C++ since 1996-ish. Less and less, for sure. Nothing the past few years. They killed it.

If you only read HN, you would think C++ died years ago. As someone who worked in HFT, C++ is very much alive and new projects continue to be created in it simply because of the sheer of amount of experts in it. (For better or for worse)

Can also confirm c++ is alive and well at FAANG. Might still be the most popular language for most new projects.

Re: 21st Century C++

#128

Post by Maxatar »

nialv7 wrote: post #118

How does enforcing profiles per-translation unit make any sense? Some of these guarantees can only be enforced if assumptions are made about data/references coming from other translation units.

This is the one major stumbling block for profiles right now that people are trying to fix.

C++ code involves numerous templates, and the definition of those templates is almost always in a header file that gets included into a translation unit. If a safety profile is enabled in one translation unit that includes a template, but is omitted from another translation unit that includes that same template... well what exactly gets compiled?

The rule in C++ is that it's okay to have multiple definitions of a declaration if each definition is identical. But if safety profiles exist, this can result in two identical definitions having different semantics.

There is currently no resolution to this issue.

Re: 21st Century C++

#129

Post by mempko »

justanotheratom wrote: post #127

C++ should be known for the amount of collective brain cycles wasted on arguing what subset of C++ is the right one to use.

Professionals know what tool to use for a job. Does it take time to become good? Of course, like anything.

Re: 21st Century C++

#130

Post by juliangmp »

Maxatar wrote: post #128
nialv7 wrote: post #118

How does enforcing profiles per-translation unit make any sense? Some of these guarantees can only be enforced if assumptions are made about data/references coming from other translation units.

This is the one major stumbling block for profiles right now that people are trying to fix. C++ code involves numerous templates, and the definition of those templates is almost always in a header file that gets included into a translation unit. If a safety profile is enabled in one translation unit that includes a template, but is omitted from another translation unit that includes that same template... well what ex…

I guess modules are supposed to be the magic solution for that, Bjarne has shown them in this article, even using import std.

Its a bit optimistic cause modules are still not really a viable option in my eyes, because you need proper support from the build systems, and notably cmake only has limited support for them right now.

Post reply on HN