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

201–210 of 470 posts

Re: In Defense of C++

#201

Post by alkonaut »

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…

I'm a developer since 30 years. I program C#, Rust, Java, some TS etc. I can probably go to most repositories on github and at least clone and build them. I have failed - repeatedly - to build even small C++ libraries despite reasonable effort. And that's not even _writing any C++_. Just installing the tooling around CMake etc is completely Kafkaesque.

The funniest thing happened when I needed to compile a C file as part of a little Rust project, and it turned out one of the _easiest_ ways I've experienced of compiling a tiny bit of C (on Windows) was to put it inside my Rust crate and have cargo do it via a C compiler crate.

Re: In Defense of C++

#202

Post by jcelerier »

wvenable wrote: post #77
butterisgood wrote: post #55

Earlier quoted context omitted.

Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!) I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?). What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck! I have hope for C++front/Cpp2. http…

Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.

If you've done any university-level maths you should have seen the + sign used in many other contexts than adding numbers, why should that be a problem when programming?

Re: In Defense of C++

#203

Post by menaerus »

duped wrote: post #93
palata wrote: post #83

Earlier quoted context omitted.

I can use pkg-config just fine. Not sure how relevant the "in order to use a tool, you need to learn how to use the tool". Or from the other side: not sure what I should think about the quality of the work produced by people who don't want to learn relatively basic skills... it does not take two PhDs to understand how to use pkg-config.

I'm just pointing out that one reason devex sucks in C++ is because the fact you need a wide array of tools, that are non portable, and require learning and teaching magic incantations at the command line or in build scripts to work, doesn't foster what one could call a "good" experience. Frankly the idea that your compiler driver should not be a basic build system, package manager, and linker is an idea best left in…

For most people this is a feature not a bug as you suggest. It may come across as PITA, and for many people will do, but as far as I am concerned, while also having experienced the pain of package managers in C++, this is the right way. In the end it's always about the trade-offs. And all the (large) codebases that used conan, bazel or vcpkg induced a magnitude more issues that you would have to handle which otherwise in a plain CMake you would not have. Package managers are for convenience but not all projects can afford themselves the trouble this convenience brings with it.

Re: In Defense of C++

#204

Post by dayvster »

camkego wrote: post #86

The article says "I think the biggest factor is that any rewrite of an existing codebase is going to yield better results than the original codebase.". Yeah, sorry, but no, ask some long-term developers about how this often goes.

Hi author of the article here.

I've been a software developer for nearly 2 decades at this point, contributed to several rewrites and oversaw several rewrites of legacy software.

From my experience I can assure you that rewriting a legacy codebase to modern C++ will yield a better and safer codebase overall.

There are multiple factors that contribute to this, such one of which is what I reffer to as "lessons learnt" if you have a stable team of developers maintaining a legacy codebase they will know where the problematic areas are and will be able to avoid re-creating them in a rewrite.

An additonal factor to consider is that a lot of legacy C++ codebases can not be upgraded to use modern language features like smart pointers. The value smart pointers provide in a full rewrite can not be overstated.

Then there's also the factor that is a bit anecdotal which is I find that there are less C++ devs in general as there was 15 years ago, but those that stayed / survived are generally better and more experienced with very few enthusiastic juniors coming in.

I'm sorry you did not enjoy the article though, but thank you for giving it your time and reading it that part I really appreciate.

Re: In Defense of C++

#205

Post by jcelerier »

o11c wrote: post #127
aw1621107 wrote: post #102

Earlier quoted context omitted.

> C++20 does have C11's designated initialization now, which helps in some cases, but that was a pain for a long time. C++ designated initializers are slightly different in that the initialization order must match the declared member order. That is not required in C.

It also completely negates their utility, even though the exact "problem" they always bring up is already solved when you use normal constructors.

Not sure I understand, since they're available in c++ designated initializes are one of the features I use most, to the point of making custom structs to pass the arguments if a type cannot be changed to be an aggregate. It makes a huge positive difference in readability and has helped me solve many subtle bugs ; and not initializing things in order will throw a warning so you catch it immediately in your ide

Re: In Defense of C++

#206

Post by jamesdhutton »

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

Maybe you can do that. But you are probably working in a team. And inevitably someone else in your team thinks that operator overloading and template metaprogramming are beautiful things, and you have to work with their code. I speak from experience.

Re: In Defense of C++

#207

Post by mirpa »

ergonaught wrote: post #167

It's a fine post except for this: > Countless companies have cited how they improved their security or the amount of reported bugs or memory leaks by simply rewriting their C++ codebases in Rust. Now is that because of Rust? I’d argue in some small part, yes. Just delete this. Even an hour's familiarity with Rust will give you a visceral understanding that "Rewrites of C++ codebases to Rust always yield more memory-s…

It reminded me of Firefox attempts at rewriting part of C++ codebase and failing - because of C++ complexity; but succeeding later because of Rust https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...

Re: In Defense of C++

#208

Post by jcelerier »

ryao wrote: post #110
monkeyelite wrote: post #97

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C. Problem 1: You might fail to initialize an object in memory correctly. Solution 1: Constructors. Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call. Solution 2: Placement new Problem 3: Now the ty…

But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.

Re: In Defense of C++

#209

Post by oytis »

jandrewrogers wrote: post #146
MBCook wrote: post #104

Earlier quoted context omitted.

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. Even if we take this claim at face value, isn’t that great ? Memory safety is a HUGE source of bugs and security issues. So the author is hand-waving away a really really good reason to use Rust (or other memory safe by default language). Overall I agree this seems a lot like “I li…

I think this is a case of two distinct populations being inappropriately averaged. There are many high-level C++ applications that would probably be best implemented in a modern GC language. We could skip the systems language discussion entirely because it is weird that we are using one. There are also low-level applications like high-performance database kernels where the memory management models are so different th…

Rust is a systems programming language, it was absolutely designed with the second use case in mind.

Re: In Defense of C++

#210

Post by dayvster »

Author of the article here.

Really appreciate and value everyone's feedback on this.

I can not overstate my excitement that my blog post has generated this much discussion and debate.

Post reply on HN