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

81–90 of 470 posts

Re: In Defense of C++

#81

Post by Night_Thastus »

zahlman wrote: post #80
Night_Thastus wrote: post #75

Earlier quoted context omitted.

Unfortunately that Wheel situation was far enough back now that I don't have details on hand. I just know it was awful at the time. As for significant whitespace, the problem is that I'm often dealing with files with several thousand lines of code and heavily nested functions. It's very easy to lose track of scope in that situation. Am I in the inner loop, or this outer loop? Scrolling up and down, up and down to fig…

Pip has changed a lot in the last few years, and there are many new ecosystem standards, along with greater adoption of existing ones. > I'm often dealing with files with several thousand lines of code and heavily nested functions. This is the problem. Also, a proper editor can "fold" blocks for you. > Being able to see the type of data at a glance tells me a LOT about what the code is doing and how it's doing it - a…

>This is the problem. Also, a proper editor can "fold" blocks for you.

I can't fix that. I just work here. I've got to deal with the code I've got to deal with. And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope.

>Sure, but then you have to understand the assembly that you've stepped into.

Assembly? I haven't touched raw assembly since college.

Re: In Defense of C++

#82

Post by zahlman »

Night_Thastus wrote: post #81
zahlman wrote: post #80

Earlier quoted context omitted.

Pip has changed a lot in the last few years, and there are many new ecosystem standards, along with greater adoption of existing ones. > I'm often dealing with files with several thousand lines of code and heavily nested functions. This is the problem. Also, a proper editor can "fold" blocks for you. > Being able to see the type of data at a glance tells me a LOT about what the code is doing and how it's doing it - a…

>This is the problem. Also, a proper editor can "fold" blocks for you. I can't fix that. I just work here. I've got to deal with the code I've got to deal with. And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope. >Sure, but then you have to understand the assembly that you've stepped into. Assembly? I haven't touched raw assembly since college.

> And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope.

How exactly are they more helpful than following the line of the indentation that you're supposed to have as a matter of good style anyway? Do you not have formatting tools? How do you not have a tool that can find the top of a level of indentation, but do have one that can find a paired brace?

>Assembly? I haven't touched raw assembly since college.

How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source?

Re: In Defense of C++

#83

Post by palata »

duped wrote: post #57
jandrese wrote: post #12

Earlier quoted context omitted.

In Linuxland you at least have pkg-config to help with package management. It's not perfect but neither is any other package management solution. If I'm writing a small utility or something the Makefile typically looks something like this: CC=clang PACKAGES=libcurl libturbojpeg CFLAGS=-Wall -pedantic --std=gnu17 -g $(shell pkg-config --cflags $(PACKAGES)) LDLIBS=$(shell pkg-config --libs $(PACKAGES)) ALL: imagerunner…

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

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.

Re: In Defense of C++

#84

Post by the_af »

jasperry wrote: post #74
the_af wrote: post #35

Earlier quoted context omitted.

You left out the full argument (to be clear, I don't agree with the author, but in order to disagree with him you have to quote the full argument): The author is arguing that the main reason rewriting a C++ codebase in Rust makes it more memory-safe is not because it was done in Rust, but because it benefits from lessons learned and knowledge about the mistakes done during the first iteration. He acknowledges Rust wi…

The argument could be made that rewriting in general can make a codebase more robust, regardless of the language. But that's not what the article does; it makes it specifically about memory safety: > That’s how I feel when I see these companies claim that rewriting their C++ codebases in Rust has made them more memory safe. It’s not because of Rust, it’s because they took the time to rethink and redesign... If they g…

My only objection to your initial comment was that you left out the main gist of the argument (your later paraphrase says the same as I did).

I'm not defending TFA, I'm saying if you're going to reject the argument you must quote it in full, without leaving the main part.

Re: In Defense of C++

#85

Post by palata »

bluGill wrote: post #26
Night_Thastus wrote: post #23

When it comes to programming, I generally decide my thoughts based on pain-in-my-ass levels. If I constantly have to fiddle with something to get it working, if it's fragile, if it frequently becomes a pain point - then it's not great. And out of all the tools and architecture I work with, C++ has been some of the least problematic. The STL is well-formed and easy to work with, creating user-defined types is easy, it…

CMake is not a great language, but great effort has been put into cleaning up how things should be done. However you can't just upgrade, someone needs to go through the effort of using all that new stuff. In almost all projects the build system is an after thought that developers touch as little as possible to make things work and so it builds cruft constantly. You can do much better in CMake if you put some effort i…

I agree. Unless the project is huge, it's totally possible to use CMake in a maintainable way. It just requires some effort (not so much, but not nothing).

Re: In Defense of C++

#86

Post by camkego »

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.

Re: In Defense of C++

#87

Post by pklausler »

AaronAPU wrote: post #72
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…

I’ve been programming C++ on a daily basis for more than 20 years and literally never use the >> operator. Never. Not rarely, never.

How do you shift bits to the right?

Re: In Defense of C++

#88

Post by casey2 »

gmueckl wrote: post #24

C++ will always stay relevant. Software has eaten the world. That transition is almost complete now. The languages that were around when it happened will stay deeply embedded in our fundamental tech stacks for another couple decades at least, if not centuries. And C and C++ are the lion's share of that. COBOL sticks around 66 years after its first release. Fortran is 68 years old and is still enormously relevant. Muc…

I'm not so sure. The user experience has really crystallized over the years. It's not hard to imagine a smart tv or something like it just reimplementing that experience in hardware in the not too distant future (say 2055 if transistor and memory scaling stall in 2035).

We live in a special time when general processing efficiency has always been increasing. The future is full of domain specific hardware (enabling the continued use of COBOL code written for slower mainframes). Maybe this will be a half measure like cuda or your c++ will just be a thin wrapper around a makeYoutube() ASIC

Of course if there is a breakthrough in general purpose computing or a new killer app it will wipe out all those products which is why they don't just do it now

Re: In Defense of C++

#89

Post by binary132 »

ktpsns wrote: post #29
gmueckl wrote: post #24

C++ will always stay relevant. Software has eaten the world. That transition is almost complete now. The languages that were around when it happened will stay deeply embedded in our fundamental tech stacks for another couple decades at least, if not centuries. And C and C++ are the lion's share of that. COBOL sticks around 66 years after its first release. Fortran is 68 years old and is still enormously relevant. Muc…

As long as people write software (no pun intended), software will follow trends. For instance, in many scientific ecosystems, Matlab was successfully replaced by Scipy. Which happens to get replaced by Julia. Things don't neccessarily have to stay the same. Interestingly, such a generational trend currently happens with Rust, despite there has been numerous other popular languages such as D or Zig which didn't have t…

You’re thinking of software that is being written today. GP is talking about software we use every day in every device on the planet that hasn’t changed since it was written 30+ years ago.

Re: In Defense of C++

#90

Post by pdpi »

pklausler wrote: post #87
AaronAPU wrote: post #72

Earlier quoted context omitted.

I’ve been programming C++ on a daily basis for more than 20 years and literally never use the >> operator. Never. Not rarely, never.

How do you shift bits to the right?

Manipulating bit patterns isn't really that common in most workloads.
Post reply on HN