Live data from Hacker News

C++ Should Be C++

open-std.org

101–110 of 191 posts

Re: C++ Should Be C++

#101
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 d…

I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++.

Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html

I tried to read C++’s vec class when I was learning C++ and I was confused and lost. I agree with the GP post - it feels like another language.

Re: C++ Should Be C++

#102

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.

I think the great challenge with breaking changes is demonstrating how other systems have done breaking changes with great success. They are quite rare. And no, the python2->python3 migration is not one of them. Neither is ip4->ip6.

Re: C++ Should Be C++

#103
post #8

Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previ…

In critical embedded development they snapshot the entire VM containing the OS, compilers, entire tool chain, and everything else.

Re: C++ Should Be C++

#104
post #13
post #4

Earlier quoted context omitted.

I don't know if you're in the minority or I am, but I find modern C++ to be borderline intolerable (and I've been programming mostly in C++ from before there were C++ compilers). I used to love C++ (and still do if we're talking about older standards), but the new stuff is just a baroque torture.

Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.

I’m excited for Zig for this reason. I’ve been writing a lot of rust lately and - well, it’s fine. Good at what it’s trying to do. But Zig seems a lot more fun. Much more in the spirit of C.

Re: C++ Should Be C++

#105
post #43

Earlier quoted context omitted.

I mean the statement you quote is undeniable. If something is used by millions as a general-purpose programming language it is fit to the task, regardless of the alternatives or how ideal it is.

That depends on your criteria for fitness. There are millions of people using homeopathic remedies. That doesn't mean that homeopathy is actually fit for any of the tasks that people employ it for.

You know that people actually write complex software in C++ right whereas homeopathy does not achieve anything.

Re: C++ Should Be C++

#106
post #43

Earlier quoted context omitted.

That depends on your criteria for fitness. There are millions of people using homeopathic remedies. That doesn't mean that homeopathy is actually fit for any of the tasks that people employ it for.

You know that people actually write complex software in C++ right whereas homeopathy does not achieve anything.

I know that some people write complex software in C++. I suspect that number is actually very small.

Re: C++ Should Be C++

#107
post #13

Earlier quoted context omitted.

Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.

You can still have "C with Classes" in modern C++ if you really want that. Just set a style guide that limits your code to that. There's more viable coding styles in C++ than I can honestly even bother to count. There's absolutely no reason to limit the language to one specific coding style when doing so would alienate large groups of users and you can set those limits yourself on your project.

Yeah, I know and that's how I've been using it for the past decade, but it's not that simple. The language keeps changing and this forces adding cruft to the code if one wants to use newer compilers.

For example, there are cases where the existence of move semantics necessitates adding some boilerplate when working with STL containers. There's no functional reason for it, just something to please the compiler.

Re: C++ Should Be C++

#108
post #99
post #51

Earlier quoted context omitted.

And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.

There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

> As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once.

That's one of the things that can slow compilation down but it's definitely not the only one. It helps that precompiled headers (and maybe modules?) can go a long way towards reducing and possibly eliminating these costs as well.

I think some (most?) of the larger remaining costs revolve around template instantiation, especially it impacts link times as well due to the fact that the linker needs to do extra work to eliminate redundant instantiations.

Re: C++ Should Be C++

#109
post #13

Earlier quoted context omitted.

Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.

I just want a C with templates (and function overloading)?

"this" and virtual functions are pretty damn useful too.

Re: C++ Should Be C++

#110
post #13

Earlier quoted context omitted.

Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.

I’m excited for Zig for this reason. I’ve been writing a lot of rust lately and - well, it’s fine. Good at what it’s trying to do. But Zig seems a lot more fun. Much more in the spirit of C.

To each their own, but I find zig syntax to be on the ugly side and the resulting code unelegant.
Post reply on HN