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

311–320 of 470 posts

Re: In Defense of C++

#311

Post by pjmlp »

pornel wrote: post #133
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…

It seems likely that C++ will end up in a similar place as COBOL or Fortran, but I don't see that as a good future for a language. These languages are not among the top contenders for new projects. They're a legacy problem, and are kept alive only by a slowly shrinking number of projects. It may take a while to literally drop to zero, but it's a path of exponential decay towards extinction. C++ has strong arguments f…

It will take generations to fully bootstrap compiler toolchains, language runtimes, and operating systems that depend on either C or C++.

Also depending on how AI assisted tooling evolves, I think it is not only C and C++ that will become a niche.

I already see this happening with the amount of low-code/no-code augmented with AI workflows, that are currently trending on SaaS products.

Re: In Defense of C++

#312

Post by lelanthran »

raverbashing wrote: post #292
bayindirh wrote: post #280

Earlier quoted context omitted.

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…

> we shall not forget that all processors are C VMs This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect It makes you think it is close which in some sense is even worse

> This idea is some 10yrs behind.

Akshually[1] ...

> And no, thinking that C is "closer to the processor" today is incorrect

THIS thinking is about 5 years out of date.

Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by

    Okay, If C is "not close to the process", what's closer?
Assembler? After all if everything else is "Just as close as C, but not closer", then just what kind of spectrum are you measuring on, that has a lower bound which none of the data gets close to?

You're repeating something that was fashionable years ago.

===========

[1] There's always one. Today, I am that one :-)

Re: In Defense of C++

#313

Post by lelanthran »

jillesvangurp wrote: post #220

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe.

You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code.

The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their facility for the language after a short break from it.

Re: In Defense of C++

#314

Post by bluGill »

asa400 wrote: post #166
pclmulqdq wrote: post #148

Earlier quoted context omitted.

"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.

Not that npm-style package management is the best we can do or anything, but I would be more sympathetic to this argument if C or C++ had a clearly better security story than JS, Python, etc. (pick your poison), but they're also disasters in this area. What happens in practice is people end up writing their own insecure code instead of using someone else's insecure code. Of course, we can debate the tradeoffs of one…

This isn't only about security. This is about interoperability, in the real world we mix (and should mix!) C, C++, Rust, python.... In the real world lawyers audit every dependency to ensure they can legally use it. In the real world we are responsible for our dependencies and so need to audit the code.

Re: In Defense of C++

#315

Post by voxelghost »

account42 wrote: post #255
jandrewrogers wrote: post #172

Earlier quoted context omitted.

Or just rely on the compiler to automatically do trivial conversions. Which are pretty reliable these days.

I'm pretty sure the post you are responding to is not seriously suggesting using floating point multiplication and exponentiation as a performance optimization ;)

Offcourse not, that would be silly. Just overload the ^ operator like any normal person.

#include #include

class Bits { unsigned value; public: explicit Bits(unsigned v) : value(v) {}

    // Shift operator ^ : positive = left, negative = right
    Bits operator^(int shift) const {
        if (shift > 0) {
            return Bits(value > -shift);
        } else {
            return *this; // no shift
        }
    }

    friend std::ostream& operator(b.value); // print 8 bits
    }
};

int main() { Bits x(0b00001111);

    std::cout

Re: In Defense of C++

#316

Post by estimator7292 »

lelanthran wrote: post #313
jillesvangurp wrote: post #220

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their f…

Have you written significant amounts of C or C++?

Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler.

Actual uses of actual C are pretty esoteric and rare in the modern era. Everything else is varying degrees of C++.

Re: In Defense of C++

#317

Post by bluGill »

Defletter wrote: post #238
pclmulqdq wrote: post #148

Earlier quoted context omitted.

"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.

I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit because then they can gleefully point at it and pretend that any first-party package manager for C/C++ would inevitably result in the same, nevermind the other languages that do not have this issue, or have it to a far, far lesser extent. Do these cultists just not use dependencies? Are they just [probably inexpertly] reinventing e…

STOP SAYING CULTIST! The word has very strong meaning and does not apply to anyone working with C or C++. I take offense at being called a cultist just because I say C++ is not nearly as bad as the haters keep claiming it is - as well I should.

Re: In Defense of C++

#318

Post by tialaramex »

butterisgood wrote: post #55
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 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…

So, what programmers wanted (yes, already before C++ got this) was what are called "destructive move semantics".

These assignment semantics work how real life works. If I give you this Rubik's Cube now you have the Rubik's Cube and I do not have it any more. This unlocks important optimisations for non-trivial objects which have associated resources, if I can give you a Rubik's Cube then we don't need to clone mine, give you the clone and then destroy my original which is potentially much more work.

C++ 98 didn't have such semantics, and it had this property called RAII which means when a local variable leaves scope we destroy any values in that variable. So if I have a block of code which makes a local Rubik's Cube and then the block ends the Rubik's Cube is destroyed, I wrote no code to do that it just happens.

Thus for compatibility, C++ got this terrible "C++ move" where when I give you a Rubik's Cube, I also make a new hollow Rubik's Cube which exists just to say "I'm not really a Rubik's Cube, sorry, that's gone" and this way, when the local variable goes out of scope the destruction code says "Oh, it's not really a Rubik's Cube, no need to do more work".

Yes, there is a whole book about initialization in C++: https://www.cppstories.com/2023/init-story-print/

For trivial objects, moving is not an improvement, the CPU can do less work if we just copy the object, and it may be easier to write code which doesn't act as though they were moved when in fact they were not - this is obviously true for say an integer, and hopefully you can see it will work out better for say an IPv6 address, but it's often better for even larger objects in some cases. Rust has a Copy marker trait to say "No, we don't need to move this type".

Re: In Defense of C++

#319

Post by adgjlsfhk1 »

lelanthran wrote: post #312
raverbashing wrote: post #292

Earlier quoted context omitted.

> we shall not forget that all processors are C VMs This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect It makes you think it is close which in some sense is even worse

> This idea is some 10yrs behind. Akshually[1] ... > And no, thinking that C is "closer to the processor" today is incorrect THIS thinking is about 5 years out of date. Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by Okay, If C is "not…

Lots of languages at a higher level than C are closer to the processor in that they have interfaces for more instructions that C hasn't standardized yet.

Re: In Defense of C++

#320

Post by raverbashing »

lelanthran wrote: post #312
raverbashing wrote: post #292

Earlier quoted context omitted.

> we shall not forget that all processors are C VMs This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect It makes you think it is close which in some sense is even worse

> This idea is some 10yrs behind. Akshually[1] ... > And no, thinking that C is "closer to the processor" today is incorrect THIS thinking is about 5 years out of date. Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by Okay, If C is "not…

> Okay, If C is "not close to the process", what's closer?

LLVM IR is closer. Still higher level than Assembly

The problem is thus:

char a,b,c; c = a+b;

Could not be more different between x86 and ARM

Post reply on HN