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

381–390 of 444 posts

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

#381

Post by int_19h »

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

Popular languages that went for strict 1:1 mapping between modules and filesystem, like Java and Python, often end up moving away from it, or at least adding various hacks (e.g. the way you can split submodules across packages in Python).

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

#382

Post by butterisgood »

khoobid_shoma wrote: post #5

It's easier to say goodbye C++!

I've written a fair amount of C++ in my day, and this seems totally unacceptable to me.

Also my opinion seems unpopular on this topic, so I suspect some group of people that really want to get behind C++ don't like that kind of talk.

Whatever though. Rust and other newer languages are kind of giving the spaces C++ works well in a run for its money and in other ways just completely blowing it out of the water in my opinion.

It might be time to look at D again too.

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

#383

Post by humanrebar »

WalterBright wrote: post #368

I had a great time implementing a C compiler and embedding it in the D compiler so it can import C code directly. I keep toying with the idea of doing that for C++, but since C++98 the language has just gotten too complicated to reliably map onto D semantics.

I have been thinking of this D non-feature when reading up on the Carbon approach. Do you have any takes on how Carbon could be successful on mapping to C++ when D considers it too much of a reach?

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

#384

Post by int_19h »

llanowarelves wrote: post #306
phao wrote: post #258

Earlier quoted context omitted.

For numerical and scientific (high performance) jobs, possibly not that much harder than C++. For other jobs, I doubt it and would stick to C++. The issue is that, for example, you might be getting people with poor software engineering training per se. You risk hiring some very smart phd that writes code that works and runs really fast, but isn't that readable, extendable, maintainable, testable, etc.

Your second paragraph describes what I see with Python ML guys.

It's generally true for ML and data science, regardless of the language.

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

#385

Post by int_19h »

pclmulqdq wrote: post #246
philliphaydon wrote: post #126

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr ) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are l…

The idiomatic version has gotten faster since C++03 overall thanks to move semantics.

std::unique_ptr doesn't have any overhead over Foo* in code where semantics is the same (i.e. you want to delete when going out of scope) on any sensible ABI - it has the same storage size, and all operations are trivially inlineable to the same exact thing you'd do with a raw pointer. About the only time I can think of where it can be slower is when the ABI insists that a struct cannot be passed or returned in a register.

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

#386

Post by echelon »

compiler-guy wrote: post #340
echelon wrote: post #312

Earlier quoted context omitted.

This has never been my experience, and Joel isn't an all-seeing oracle. In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow. The Node.js team left wholesale to go found CockroachDB, which left nob…

No one said to let everyone have a free for all with a million different languages. Rewriting things creates its own set of bugs. Every time.

Of course it does.

But leaving things untouched is sometimes impossible or an even bigger drain.

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

#387

Post by Gibbon1 »

f1shy wrote: post #272
phao wrote: post #260

Earlier quoted context omitted.

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

In my experience 99% speculative and WRONG . Who said: "early optimization is the root of all evil"? :) Today more and more is possible to have a GC without terrible performance issues. Some weeks ago I read an article here in HN, about LISP used for safety critical systems. That bad fame of GC comes from the early versions of Java... but I've been using GC languages a LOT, and never had those "stop the world" moment…

Not my bailiwick but I feel like early Java's problem was a combination of everything not a simple primitive is an object that goes on the heap plus a GC optimized for batch throughput vs latency. Bonus it's Java all the way down to the bitter end.

I'm with you. One should look at latency requirements and the ratio of profit vs server costs when making a decision. AKA when your product generates $250k/month, you're paying three programmers $40k/month, and your AWS bill is $500/month isn't the time to try and shave pennies.

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

#388

Post by Forricide »

StephanTLavavej wrote: post #360
Forricide wrote: post #257

Earlier quoted context omitted.

I really love this talk in particular: https://www.youtube.com/watch?v=4P_kbF0EbZM (On charconv) But any of the ones I've seen from Stephan have been fantastic, I think, although I'm not actually sure if I've seen more. He seems to have a lot of talks on very specific subjects, which can be really fun. > Hyrum Wright is in the audience yelling interjections as a result of Hyrum's law This sounds absolutely hilarious,…

I'm glad you liked my charconv talk! Here's a complete list of my recorded conference talks: BoostCon/C++Now 2012: Regex In C++11 And Boost: https://youtu.be/mUZL-PRWMeg GoingNative 2012: STL11: Magic && Secrets: https://docs.microsoft.com/en-us/events/goingnative-2012/stl... GoingNative 2013: Don't Help The Compiler: https://docs.microsoft.com/en-us/events/goingnative-2013/don... GoingNative 2013: rand() Considered…

That's a way better list than what I had! Thanks! Think I'll watch the rand() talk tomorrow, I love (to hate on) rand.

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

#389

Post by WalterBright »

humanrebar wrote: post #383
WalterBright wrote: post #368

I had a great time implementing a C compiler and embedding it in the D compiler so it can import C code directly. I keep toying with the idea of doing that for C++, but since C++98 the language has just gotten too complicated to reliably map onto D semantics.

I have been thinking of this D non-feature when reading up on the Carbon approach. Do you have any takes on how Carbon could be successful on mapping to C++ when D considers it too much of a reach?

I don't know anything about Carbon. But a reasonable approach would be to use an existing C++ compiler and intercept its ASTs.

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

#390

Post by zetafunction »

int_19h wrote: post #376
mrazomor wrote: post #286

Earlier quoted context omitted.

"no exceptions" is one of the best parts of Google style guide, IMO. Note that, banning of exceptions introduced returning status (error codes done right). It makes it easier to follow the code and makes the code more readable (but, you need a few macros, unfortunately).

In a language like C++ returning status codes means that callers can and will ignore it, even when they shouldn't.

Since C++17, using [[nodiscard]] can help with that.
Post reply on HN