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

301–310 of 470 posts

Re: In Defense of C++

#301

Post by account42 »

BeetleB wrote: post #52

> Here’s a rule of thumb I like to follow for C++: make it look as much like C as you possibly can, and avoid using too many advanced features of the language unless you really need to. Also, avoid using C++ classes while you're at it. I recently had to go back to writing C++ professionally after a many-year hiatus. We code in C++23, and I got a book to refresh me on the basics as well as all the new features. And ma…

Using classes doesn't have to mean OO. Classes in C++ are important for RAII which you definitely should not avoid.

Re: In Defense of C++

#302

Post by pjmlp »

bayindirh wrote: post #280
pornel wrote: post #264

Earlier quoted context omitted.

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…

These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. Howev…

I remember, I was there in the 1980's coding, hence why I know C and C++ were not the only alternatives, rather the ones that eventually won in the end.

Re: In Defense of C++

#303

Post by dig1 »

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…

> 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 operatorPartially true. operator*() is used through the standard library a lot, because it nicely wraps pointer semantics. Still, you don't have to know about implementation details, as they depend on how the standard library implements the underlying containers.

AFAIK operator> Basic standard library datatypes like std::vector use templates, so you're debugging template instantiation issues whether you write your own templated code or not.

As long as you keep things simple, errors are going to be simple. The problem with "modern C++" is that people overuse these new features without fully comprehending their pros and cons, simply because they look cool.

Re: In Defense of C++

#304

Post by pjmlp »

imtringued wrote: post #230
jlarocco wrote: post #136

Earlier quoted context omitted.

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

I would rather deal with Makefiles than Gradle.

Re: In Defense of C++

#305

Post by pjmlp »

jimbob45 wrote: post #144
pclmulqdq wrote: post #129

Earlier quoted context omitted.

C++ has a plethora of available build and package management systems. They just aren't bundled with the compiler. IMO that is a good thing, because it keeps the compiler writers honest.

You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.

MSBuild also does C++.

Re: In Defense of C++

#306

Post by BiraIgnacio »

Does it need to be defended? Does it need to be attacked?

I take the "use it if we can/want/is forced to" and "improve it if you want and can" approaches. Or else, leave it be.

Re: In Defense of C++

#307

Post by TuxSH »

jcelerier wrote: post #212
monkeyelite wrote: post #169

Earlier quoted context omitted.

Do you see all the concepts you had to describe here? > Unless you are a low-level systems developer it is unlikely to affect you. Making new data structure is common. Serializing classes into buffers is common.

> Making new data structure is common. Serializing classes into buffers is common. You don't want std::launder for any of that. If you must create object instances from random preexisting bytes you want std::bit_cast or https://en.cppreference.com/w/cpp/memory/start_lifetime_as.h...

Alas none of gcc/clang/msvc(?) have implemented start_lifetime_as, so if you want to create an object in-place and obtain a mutable pointer to it, you're stuck with the:

    return std::launder(static_cast(std::memmove(p, p, sizeof(T))));
trick until they properly implement it. For MMIO, reintepret_cast from integer is most likely fine.

Re: In Defense of C++

#308

Post by AlienRobot »

Defletter wrote: post #233
jlarocco wrote: post #136

Earlier quoted context omitted.

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

This is pure Stockholm syndrome. If I were forced to choose between creating a cross-platform C++ project from scratch or taking an honest to god arrow to the knee, the arrow would be less painful.

I don't want any arrows in my knees but I agree.

The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies, and to solve this you use precompiled headers which you might have to set up manually dependending on what IDE you are using.

It's all too painful.

Re: In Defense of C++

#309

Post by zbentley »

jcelerier wrote: post #200
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…

> Overloaded operators like operator*() and operator you don't need to understand what an overloaded operator is doing any more than you have to understand the implementation of every function you call, recursively

I mean, you kinda do. Otherwise you won’t understand why bit-shifting to std::cout prints something, which is pretty much day 1 of C++ hello world introduction (yes, I know there are introductions that don’t use that silly syntax sugar. They’re rare, like it or not.)

Like, sure, you don’t have to understand cout’s implementation of operator That’s … a lot more to learn than, say, printf.

Re: In Defense of C++

#310

Post by zbentley »

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.

Regrettably, “intended purpose” is highly subjective.

Sure, Reasonable minds can and do differ about where the line is in many of those cases. And because of that variability of interpretation, we get extremely hard to understand code. As much as I have seen value in overloading at times, I’m forced to agree that it should probably not exist entirely.

Post reply on HN