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

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

261–270 of 444 posts

Re: C++20, How Hard Could It Be

#261

Post by tialaramex »

dataflow wrote: post #203
tialaramex wrote: post #152

Earlier quoted context omitted.

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

> Mostly deprecations mean something was deemed to be a bad idea "Most" maybe by count, but I'm not sure if it's "most" by usage frequency. There have been & will be lots of nonsensical deprecations that are much more common in existing code than "putting volatile on an object argument" (which I've honestly never even seen anyone do in my life)... like static (which was undeprecated, thankfully, but how were people s…

So as I understand this, you don't agree that std::iterator was deemed to be a bad idea?

I mean, I personally would feel comfortable defending the idea that is a bad idea, but that's not even what I'm saying, I'm only saying it was deemed to be a bad idea, which is exactly what the proposal for deprecating it explains.

Re: C++20, How Hard Could It Be

#262

Post by __jem »

phoehne wrote: post #225
synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

> Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada.

Rust is definitely difficult to learn, but I'll anecdotally say that Rust helped get me into the embedded world as someone with very little C or C++ experience. Unlike Ada, Rust has a modern toolchain and type system that feels very comfortable to developers coming from higher level languages, even if many of the concepts related to manual memory management remain quite difficult.

Re: C++20, How Hard Could It Be

#263

Post by Sharlin »

layer8 wrote: post #247
misnome wrote: post #51

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

`std::this_thread::yield` already existed at the time, and “yield” was presumed to also be a common identifier in financial and agricultural contexts. I’m nevertheless surprised that new noncontextual and previously-unreserved-identifier keywords were added at all. In earlier times, the approach would have been to use a reserved identifier like “_Yield” for the keyword, and to provide a standard opt-in header that wo…

I’m not sure C++ has ever used the `_Yield` hack, except for C compatibility? C on the other hand uses it all the time.

Re: C++20, How Hard Could It Be

#264

Post by tele_ski »

dureuill wrote: post #84
karterk wrote: post #46

Earlier quoted context omitted.

What are some ways in which they are bad/broken?

modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo:…

Yikes, I was so excited for modules back when I was still writing C++17 and a bit of early 20. Sad they have so many problems with them and/or are just plain not implemented still. Honestly I'm happy I'ved moved on from the language

Re: C++20, How Hard Could It Be

#265

Post by TinkersW »

phoehne wrote: post #225
synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

Go isn't a competitor to C or C++. I don't know where that idea even comes from. Go is competing with Java and web languages.

Rust is the only real competitor, but given the sheer amount of existing C and C++ code, the idea that they will become legacy languages any time soon is pretty out to lunch.

Re: C++20, How Hard Could It Be

#266

Post by spoiler »

newobj wrote: post #155
spoiler wrote: post #43

Earlier quoted context omitted.

I've always preferred clang for its better lints, and friendlier error messages (sans some decrepit parts around templates that are equally horrendous everywhere)... And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is. Also, it's been a few years n…

clang doesn't output asm

I'm not sure what you mean? You can use `-S`

Re: C++20, How Hard Could It Be

#267

Post by f1shy »

Xeamek wrote: post #212
synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

>Java for enterprise or Android >C# if you are windows developer Picking Java over kotlin for android, or lumping C# into "just for windows" bucket is exactly the ignorance that leads you to "we don't have choices" conclusion. If you always default to literally top1 language for given domain, then how can you expect to have multiple choices? I'm not talking about using some brand new gimmick that came out yesterday a…

TBH I was shocked by "Python for machine learning". I do not know where that comes from. Maybe because some important toolkits are available for Neural Networks? But machine learning is not neural networks... you can do it with NNs, but there are so many other algorithms... I'm really surprise of this kind of posts in hacker news. I thought the audience here has other experiences.

Re: C++20, How Hard Could It Be

#268

Post by f1shy »

oconnor663 wrote: post #238
synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

I think depending on the type of project, Rust might already be there. A couple of bullets raise questions: > ready to use tooling support This really depends on the use case. If the tooling you're looking for is "Unreal Engine", then Rust is definitely not there yet. But if you want to write network services, databases, CLI tools, etc., I think Rust has been fully viable with good tooling and library support for yea…

And also you have to check the quality, not only quantity... yes, you get many people if you search "c++ developers" but how good are they? I think people who are into Rust are very motivated, curious people, with some experience. I would really like a study of that, btw :)

Re: C++20, How Hard Could It Be

#269

Post by pyjarrett »

__jem wrote: post #262
phoehne wrote: post #225

Earlier quoted context omitted.

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

> Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada. Rust is definitely difficult to learn, but I…

> Unlike Ada, Rust has a modern toolchain

We have a modern toolchain too :)

    # install compiler and build tools
    alr toolchain --select

    # make, build and run a project
    alr init --bin my_project
    alr build
    alr run
Post reply on HN