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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

431–440 of 470 posts

Re: In Defense of C++

#431

Post by einpoklum »

steveklabnik wrote: post #376
einpoklum wrote: post #367

Earlier quoted context omitted.

It is a big deal even after you know how it works. The thing is, the languages like Rust only make this easier within their controlled "garden". But for C and C++, you build in the "world outside the garden" to begin with, where you are not guaranteed of everyone having prepared everything for you. So, it's harder, and you may need third-party tools or putting in some elbow grease, or both. The upside is that when ru…

What is "outside the garden" for Rust?

Oh, say, use some binary C library with some header, that you found on some system.

Re: In Defense of C++

#432

Post by hiimkeks »

einpoklum wrote: post #431
steveklabnik wrote: post #376

Earlier quoted context omitted.

What is "outside the garden" for Rust?

Oh, say, use some binary C library with some header, that you found on some system.

That shouldn't be too tricky, assuming the binary is built for the sort of device you want to run on. At least not much more complicated than calling any other C code, using bindgen.

Re: In Defense of C++

#433

Post by DarkNova6 »

blindseer wrote: post #190

I would really like to see more people who have never written C++ before port a Rust program to C++. In my opinion, one can argue it may be easy to port initially but it is an order of magnitude more complex to maintain. Whereas the other around, porting a C++ program to Rust without knowing Rust is challenging initially (to understand the borrow checker) but orders of magnitude easier to maintain. Couple that with e…

> Couple that with easily being about to `cargo add` dependencies and good language server features, and the developer experience in Rust blows C++ out of the water.

Exactly this. Regardless of safety, expressiveness, control, whatever argument someone pulls from their hat to defend C++ the simple fact of a solid dependency manager cannot be overstated.

Re: In Defense of C++

#434

Post by palata »

Defletter wrote: post #424
palata wrote: post #405

Earlier quoted context omitted.

> Your defensiveness Start by not calling everybody disagreeing with you a cultist, next time. > I said system package, not official repository. I don't know why you keep insisting on countering an argument I did not make. Yes, system packages can be installed from unofficial repositories. I don't know how I could've made this clearer. It's not that it is unclear, it's just that it doesn't make sense. When we compare…

> Start by not calling everybody disagreeing with you a cultist, next time. You'd do very well as a culture war pundit. Clearly I wasn't describing a particular kind of person, no, I'm clearly I'm just talking about everyone I disagree with /s

So, not interested at all in how to deal with dependencies without git submodules, I reckon?

We can stop here indeed.

Re: In Defense of C++

#435

Post by almostgotcaught »

112233 wrote: post #183
loeg wrote: post #45

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for m…

Exactly, the "you dont have" part lasts until the first error message and then it's 10 feet of stl template instantiation error avalanche. And stl implementation is really advanced c++ . Also, a lot of "modern" code cannot be debugged at all (because putting in a print statement breaks constexprness) and your only recourse is reading code. This is in big part also because of committee, that prefers hundred-line templ…

> your only recourse is reading code

Oh the horror!

Re: In Defense of C++

#436

Post by DarkNova6 »

s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

> Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies.

This is a strawman argument. Just because pip and npm are a mess and security liabilities does not make the c++ situation less bad. A fair comparison would be for languages that got their act together and use cargo, maven or nuget.

Linus is also not alone with his opinion in favouring Rust over C++. I would be hard pressed to use his persona in a negative case.

Re: In Defense of C++

#437

Post by steveklabnik »

hiimkeks wrote: post #432
einpoklum wrote: post #431

Earlier quoted context omitted.

Oh, say, use some binary C library with some header, that you found on some system.

That shouldn't be too tricky, assuming the binary is built for the sort of device you want to run on. At least not much more complicated than calling any other C code, using bindgen.

Yep, Rust made design decisions to make this case as zero overhead as it can be.

Re: In Defense of C++

#438

Post by illuminator83 »

the_af wrote: post #43
pie_flavor wrote: post #33

I don't think there could be any purer of an expression of the Blub Paradox. > Just use whatever parts of the language you like without worrying about what's most performant! It's not about performant. It's about understanding someone else's code six months after they've been fired, and thus restricting what they can possibly have done. And about not being pervasively unsafe. > "I don’t think C++ is outdated by any s…

> In fact the entire narrative of 'you'll get it better the second time' is nonsense, the software being rewritten was usually written for the first time by totally different people, and the rewriters weren't around for it or most of the bugfixes. They're all starting fresh, the development process is nearly the same as the original blank slate was - if they get it right with Rust, then Rust is an active ingredient i…

Well, I think some people underestimate how old and badly written a lot of software can be.

I've seen some seriously bad legacy code bases. In fact, I've spent many years of my career hired specifically to redesigning and rewriting software. Either legacy code or code that wasn't written by pro software engineers in the first place (e.g. engineers of other fields or scientists with various specializations).

And thus, I also observe that many people aren't aware how much software (in production) was created by people for whom creating software is a secondary or tertiary interest and skill at best.

And yes, typically it gets much better when rewritten later and by a pro.

Not all software needs that, it doesn't always work. But it needs to happen quite often for the software to stay maintainable and extensible with new features. In a lot of these cases only the original author would even dare to touch it. Good for short term job security, bad for the company.

And it isn't a requirement for the original authors to be involved (though that helps a lot usually).

I myself rewrite my own code quite often and tend to refactor and iterate on it a lot. The first shot is rarely good. But it get's good after a while.

Re: In Defense of C++

#439

Post by loeg »

einpoklum wrote: post #429
dig1 wrote: post #303

Earlier quoted context omitted.

> You have to learn about what the insane move semantics are (and the syntax for move ctors/operators) to do fairly basic things with the language That is simply not true. You can write a lot of C++ code without even touching move stuff. Hell, we've been fine without move semantics for the last 30 years :P > Overloaded operators like operator*() and operator Partially true. operator*() is used through the standard li…

> operator Not that widely. You must be thinking of the IO streams part of the library. Yes, it's rather poor in many respects. But you don't have to use it! We have perfectly nice variadic printing functions these days! auto number = 42; std::println("Hello, {}! The answer is {}", "world", number);

std::println dates to C++23. This is very recent. You only have to be using Clang 18 (March 2024) or older to find the feature unsupported: https://godbolt.org/z/xPqYafhss (Clang 19 dates to September 2024, only a year ago.)

In contrast, the standard C++ stream types have used operator<< overloading for more than 25 years. glog/gtest assertions continue to use it.

Re: In Defense of C++

#440

Post by jonstewart »

einpoklum wrote: post #410
jonstewart wrote: post #14

Earlier quoted context omitted.

Catch2 is great as a unit test framework. Running unit tests with the address sanitizer and UB sanitizer enabled go a long way towards addressing most memory safety bugs. The kind of C++ you write then is a far cry from what the haters complain about with bad old VC6 era C++.

> Catch2 is great as a unit test framework. It's "great" mainly in the sense of being very large, and making your code very lage - and slow to build. I would not recommend it unless you absolutely must have some particular feature not existing elsewhere. Here's a long list of C++ unit testing frameworks: https://en.wikipedia.org/wiki/List_of_unit_testing_framework... And you might consider: * doctest: https://github.…

I guess I consider it great in comparison to CppUnit, Boost Test, and Google Test. I also like that it incorporated nonius, that's a big win.
Post reply on HN