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

71–80 of 191 posts

Re: C++ Should Be C++

#71

Post by andrewmcwatters »

MaulingMonkey wrote: post #56
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…

I'll make a similar, but fundamentally different, claim to what you're quoting: There isn't much demand for half assed memory safety features. And C++ memory safety features are - nearly by definition - half assed. They're opt-in (meaning all the third-party and system code you link against doesn't have coverage), slow (meaning you can't use it in production), and tend to catch the trivial bugs rather than the hard-t…

Reminds me of "type-safety" features in duck type languages.

Re: C++ Should Be C++

#72

Post by gavinray »

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.

Re: C++ Should Be C++

#73

Post by andrewmcwatters »

samsquire wrote: post #60

I hope people don't throw out the effective and well-thought out parts with the problematic parts. It happened with Macromedia Flash and it happened with Microsoft's Visual Basic. The JVM and industry attitudes to Java. PHP. We have lost some good technology over time, please don't let us lose the good parts of C++.

For whatever reason, the software industry never learns this lesson. Maybe because people would rather move on to something new entirely and new entrants are not aware of what they're losing at all.

Re: C++ Should Be C++

#74

Post by professoretc »

galkk wrote: post #16

I like that this doc at least says that C++ is unergonomic. I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. And when you look into C++ libraries/stdlib, they often look like they're written in another language entirely. This is not normal.

> I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations.

Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code.

(I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)

Re: C++ Should Be C++

#75

Post by andrewmcwatters »

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.

Re: C++ Should Be C++

#76

Post by paulddraper »

lisper wrote: post #54
paulddraper wrote: post #50

Earlier quoted context omitted.

No, your analogy falls over. The equivalent assertion is "Christianity is a good/useful belief system" (and "Islam is a good/useful belief system") Now, you could endeavor to disprove that equivalent assertion, but your earlier argument doesn't.

My argument applies equally well to that: the mere fact that a religion has large numbers of adherents does not in and of itself show that it is either good or useful. But that's a harder case to make because it turns on what is meant by "good" and "useful", and those are things about which reasonable people can disagree. To be clear, "fitness as a general purpose programming language" is also something about which r…

Your argument is "large numbers of people can be wrong, as shown by the fact that either Christians or Muslims are wrong."

But metaphysics/religion is different than programming language utility.

We can expect a higher degree of accurate judgment in the latter.

Re: C++ Should Be C++

#77

Post by fl0ki »

> However, I don’t want to give the impression we should say no to all proposals. There are plenty of opportunities to improve our user’s lives through proposals. Here are a few concrete examples: [all 3 are just library additions that exist outside the standard already]

This may not have been the intent, but the way I read it, it's saying that language evolution is now pointless and only library additions can be considered. That would be a pretty dire situation for C++ overall.

Never mind that this means many language issues will never be fixed, it would also mean that implementations face the burden of yet more standard library additions which quickly fall behind external libraries because of the added burden of ABI lockin, and now multiplied by several vendors vs just one third party library.

Re: C++ Should Be C++

#78

Post by Kranar »

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.

This is not pedantic at all. Aliasing issues are really subtle and hinder so many optimizations. It's not clear that there is a way to even fix this without substantially breaking backwards compatibility.

Re: C++ Should Be C++

#79

Post by Kranar »

zozbot234 wrote: post #34
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…

Why does this have to be part of the standard library? Isn't that the whole point of Boost, that one is not limited to what's in std?

Boost has its uses and in many cases it's an improvement over the standard library, but performance isn't one of its key properties. Some parts of boost are about as fast as they can be, but that's the exception.

Re: C++ Should Be C++

#80

Post by lisper »

paulddraper wrote: post #76
lisper wrote: post #54

Earlier quoted context omitted.

My argument applies equally well to that: the mere fact that a religion has large numbers of adherents does not in and of itself show that it is either good or useful. But that's a harder case to make because it turns on what is meant by "good" and "useful", and those are things about which reasonable people can disagree. To be clear, "fitness as a general purpose programming language" is also something about which r…

Your argument is "large numbers of people can be wrong, as shown by the fact that either Christians or Muslims are wrong." But metaphysics/religion is different than programming language utility. We can expect a higher degree of accurate judgment in the latter.

> metaphysics/religion is different than programming language utility.

Of course it is. But religions make mutually exclusive objective claims. Metaphysics has nothing to do with it.

Post reply on HN