Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Should Be C++

open-std.org

Post reply on HN
Print view View original

81–90 of 191 posts

Re: C++ Should Be C++

#81

Post by trealira »

lisper wrote: post #65
CuriousCosmic wrote: post #64

Earlier quoted context omitted.

"adoption of X is a testament that it is fit for purpose" and "adoption of X is a testament of truth" are two incredibly different things. The equivalent statement would be that "adoption by millions is a testament to the viability of X as a cohesive religion".

"Fitness as a general purpose programming language" is (at least in part) an objective claim. If a million people professed to believe that, say, brainfuck was fit as a general purpose programming language that in and of itself would not make it so. This is not the case for being a cohesive religion. If a million people profess to believe some religious belief, that in and of itself is sufficient for that belief to b…

> If a million people professed to believe that, say, brainfuck was fit as a general purpose programming language that in and of itself would not make it so.

No, but if millions of people actually did manage to use Brainfuck for general purpose programming, then that would be evidence that it really is fit as a general purpose programming language, even if it's not ideal.

Brainfuck isn't in that position, hence no one thinks it's fit, but C++ is. People do use it for general purpose programming, even if their program could be rewritten in a garbage-collected language.

Re: C++ Should Be C++

#82

Post by chris_wot »

andrewmcwatters wrote: post #75
chris_wot wrote: post #58

I have seen that the biggest issue with C++ is that legacy C++ is quite hard to refactor to the new patterns. For example, I have been working on font substitution in LibreOffice, and I'd like to use a more functional style of programming, but I'm getting stuck because of an overuse of classes. I've been reading Functional Programming in C++ by Ivan Cukic and I'd like to adopt this - it does require a lot of refactor…

I think this is one place where you're totally working against the language. Edit: I don't know how you can arrive at this conclusion given the history of the language. The STL isn't the C++ standard library. I would love to discuss this more, but dang has limited and nerfed my account.

Not really. Look at the standard template library. It’s not really using classes with inheritance. It’s using non-member functions, often with iterators.

Ironically I’ve just learned, however, that lambdas are actually anonymous classes! I’m currently up to the bit in yhe book I referred to before that explains how to do currying in C++.

The more I read, the more I think I’m working against the code base than I am against C++. I’m actually very curious how ranges work, something the book talks about later.

Re: C++ Should Be C++

#83

Post by wheels »

lisper wrote: post #44
wheels wrote: post #41

Earlier quoted context omitted.

Yeah, probably should have left the religion analogy out. It wasn't essential to the point you were making and was based on a false model of religion. There's actually a pretty complex matrix in religious disagreement with or without exclusivity. And not all religions are exclusive at all. Islam's views of other Abrahamic religions is complicated, but it is exclusive about non-Abrahamic religions. Christianity sees J…

What would have been a better example? The problem with trying to come up with examples of large numbers of people holding objectively false beliefs is that you have to look outside the realm of science. The whole point of science is that it provides a mechanism for resolving disagreements about objective truth objectively (i.e. experiment) and so you just don't get a lot of people holding objectively false beliefs,…

Most of what humans talk about isn't science or religion, and to reduce the world to just that is pretty weird to say the least. Most things can't be resolved by appeals to objective truth. It sounds like you're working on a model where that's how one resolves conflicts, but literally most of the history of knowledge, humanity, whatever label you want to put on it -- isn't that. Even science isn't by any means that binary. Disagreements can last centuries. And we're even at a spot in science where a lot of the interesting stuff fumbles around for decades before we can even come up with experiments that could possibly test it; and some of it we won't ever be able to test. (A lot of cosmology isn't testable.)

But the point me and a few others were making is that you don't seem to know much about religion, so it's probably not a good thing to use in analogies. Religion is definitely not a set of neatly divided mutually exclusive beliefs. Almost all of the world's adherents come from two families of religions -- Abrahamic or Vedic -- and within those groups there's a whole lot of similarity and varying levels of theological exclusivity.

I feel like gambling or the stock market may be better examples. If one person takes a long position on a stock and another short, they have mutually exclusive beliefs about it, and one of them will be wrong.

Re: C++ Should Be C++

#84

Post by discreteevent »

zozbot234 wrote: post #48
jocaal wrote: post #38

Earlier quoted context omitted.

IMO the reason C++ isn't a general purpose programming language is due to memory management. Many many many applications can be built without having to worry about the garbage collector and the productivity gains of using a GC language is so so worth it. And I know you can force C++ into acting like a GC language, but why go through the effort? C++ is a precision tool for building complex and performant systems and t…

GC is not required for memory safety. The proper use of GC nowadays is for dealing with problems that inherently involve spaghetti-like reference graphs for which no other memory management strategy is suitable. Using it as mere convenience might be okay for quick prototyping, but it ultimately leads to half-baked, hard-to-refactor code requiring a lot of CPU and memory overhead at runtime.

> GC is not required for memory safety.

>memory overhead at runtime.

These statements are true. The rest is grandstanding.

Re: C++ Should Be C++

#85

Post by 29athrowaway »

tempodox wrote: post #66
29athrowaway wrote: post #29

If C++ wants to continue evolving, it needs breaking changes. It needs to impose a migration duty to the user, but that is not going to happen. So it will die a death by entropy where noone can know the language.

> it needs breaking changes. Then nobody will use the new compiler because nobody wants to rewrite millions of LOC and introduce new bugs.

AI will do it one day.

Re: C++ Should Be C++

#86

Post by [deleted] »

lisper wrote: post #12

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. No, that is false. It is akin to arguing that Christianity must be true because 2.4 billion Christians can't be wrong. The fallacy is easy to see because the argument can be applied equally to the world's 1.9 billion Muslims and 1.2 billion Hindus and 500 million Buddhists, etc. And yet these gro…

[deleted]

Re: C++ Should Be C++

#87

Post by dataangel »

gavinray wrote: post #72
CoolGuySteve wrote: post #24

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using…

> Continue being the fastest systems language possible. If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing. You'd need to smatter "_restrict" everywhere to skirt this.

> If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing.

True but the only practical competitor is Rust, and they gain some alias information (mut) and lose other aliasing information (type punning is fully allowed in unsafe code all the time).

Re: C++ Should Be C++

#88

Post by BeetleB »

EdSchouten wrote: post #6

> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view. I don’t really agree with this. There’s also a group of develo…

C++ Developers aren't complaining for two reasons:

1. Most of those who care about memory safety have already left the building.

2. Those who are still in the building and care don't speak up because their colleagues don't value it, and many of their colleagues will view them as having lower competence.

Re: C++ Should Be C++

#89

Post by IshKebab »

KerrAvon wrote: post #23

Is this a response to some specific set of proposals? I know there's been a lot of general angst / misunderstanding over C++ memory safety.

It's a response to Rust. Rust is significantly better than C++, and most importantly it's the first language that could actually replace C++ for the things C++ is generally used for.

I guess the C++ community is coming to terms with not being the top dog of "zero-cost abstraction" languages anymore.

Really I think it's too late for C++. They had literal decades to fix very basic flaws, and they just haven't done it.

Accidental octal literals. Case fall-through. Missing `return`s. Accidental string literal addition. The whole module system mess.

They focused way too much on adding complex features and not at all on fixing footguns. As a result C++ is painful and dangerous. Too late to fix IMO.

Re: C++ Should Be C++

#90

Post by spacechild1 »

Night_Thastus wrote: post #5
gavinray wrote: post #2

Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing…

Anything C++11 forward is alright with me, though 17 introduces some very nice conveniences like , and most critically . Honorable mention to std::clamp too.

I would like to add:

- structured bindings

- auto parameters in lambdas

- init statements in if and switch clauses

- template argument deduction for constructors

Post reply on HN