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

101–110 of 470 posts

Re: In Defense of C++

#101

Post by thelittlenag »

Night_Thastus wrote: post #31
justicehunter wrote: post #17

I'm not sure what I feel about the article's point on boost. It does contribute a lot to the standard library and does provide some excellent libraries, like boost.Unordered

Boost is an awful whole with a couple very nice tiny parts inside. If you can restrict to using the 'good' parts than it can be OK, but it's pulling in a huge dependency for very little gain these days.

I'm old enough to recall when boost first came out, and when it matured into a very nice library. What's happened in the last 15 years that boost is no longer something I would want to reach for?

Re: In Defense of C++

#102

Post by aw1621107 »

butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

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

Re: In Defense of C++

#103

Post by duped »

bluGill wrote: post #100
duped wrote: post #93

Earlier quoted context omitted.

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…

that idea that packages and builds belongs to simple problem, large projects need things like more than one laguage and so end up fighting the language

Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs

Re: In Defense of C++

#104

Post by MBCook »

IshKebab wrote: post #20

Terrible article. > you can write perfectly fine code without ever needing to worry about the more complex features of the language Not really because of undefined behaviour. You must be aware of and vigilant about the complexities of C++ because the compiler will not tell you when you get it wrong. I would argue that Rust is at least in the same complexity league as C++. But it doesn't matter because you don't need…

> 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 like C++and I’m good at it so it’s fine” with justifications created from there.

Re: In Defense of C++

#106

Post by zevets »

LexiMax wrote: post #98
wvenable wrote: post #77

Earlier quoted context omitted.

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.

I will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake. Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.

Alternatively, any implementation of operator+ should have a notional identity element, an inverse element and be commutative.

Re: In Defense of C++

#107

Post by MBCook »

fithisux wrote: post #6

"Rust shines in new projects where safety is the priority, while C++ continues to dominate legacy systems and performance-critical domains." the truth

Hasn’t Rust been shown to be very fast, especially since it can elide a lot of safety checks that would otherwise be necessary to prevent bugs?

On legacy code bases, sure. C++ rules in legacy C++ codebases. That’s kind of a given isn’t it? So that’s not a benefit. Just a fact.

Re: In Defense of C++

#108

Post by ants_everywhere »

gmueckl wrote: post #65
ktpsns wrote: post #29

Earlier quoted context omitted.

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…

I am not saying that these languages will stay around forever, mind you. But we have solidified the tech stacks involving these languages by making them ridiculously complex. Replacement of a programming language in one of the core components can only come through gradual and glacially slow evolution at this point. "Rewrite it in XYZ" as a clean slate approach on a big scale is simply a pipe dream. Re Matlab: I still…

I've heard via former employees that Mathworks has conceded that Python ate Matlab's niche and that they're focusing on Simulink

Re: In Defense of C++

#109

Post by benreesman »

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…

clang++ $(pkg-config --cflags --libs libtorch) qwen-3-nvfp4.cpp -o ./qwen-3-infer

Your move.

Re: In Defense of C++

#110

Post by ryao »

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 type system has led the compiler to assume your preallocated memory cannot change since you declared it const.

Solution 3: std::launder()

If it is not clear what I mean about placement new and const needing std::lauder(), see this:

https://miyuki.github.io/2016/10/21/std-launder.html

C has a very simple solution that avoids this chain. Use structured programming to initialize your objects correctly. You are not going to escape the need to do this with C++, but you are guaranteed to have to consider a great many things in C++ that would not have needed consideration in C since C avoided the slippery slope of syntactic sugar that C++ took.

Post reply on HN