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

91–100 of 191 posts

Re: C++ Should Be C++

#91

Post by JohnFen »

CuriousCosmic wrote: post #62
eps wrote: 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.

This is what I do for my own projects, but it's not a viable thing to do with my work projects since I don't set the style.

Re: C++ Should Be C++

#92

Post by zozbot234 »

dataangel wrote: post #87
gavinray wrote: post #72

Earlier quoted context omitted.

> 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).

Not so, unsafe code still has restrictions in Rust due to pointer provenance. You can override these restrictions but it's very much an explicit operation, the default is that pointers with incompatible provenance will not alias. This is how Rust models its equivalent to TBAA, and the concept is spreading to C/C++ as well.

Re: C++ Should Be C++

#93

Post by MaxBarraclough »

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…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but:

> I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible.

You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs.

C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers.

Some of your gripes with the standard library can be addressed with libraries, perhaps from the Boost project.

Re: C++ Should Be C++

#94

Post by kimixa »

andrewmcwatters wrote: post #68
diath wrote: 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…

vcpkg was dead in the water because they altered source packages. Completely unacceptable in many situations.

I also find vcpkg extremely fragile.

Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds.

Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed.

Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again.

But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed.

Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.

Re: C++ Should Be C++

#95

Post by gafferongames »

MaxBarraclough wrote: post #93
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…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers.

Compile time would also be an exception.

Re: C++ Should Be C++

#96

Post by IAmLiterallyAB »

MaxBarraclough wrote: post #93
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…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

> You've essentially described C

I'd disagree pretty strongly with that. C is more focused on being relatively simple to implement and backwards compatibility with the past 50 years. (I read a blog post by a C committee member talking about that recently, wish I could find the link)

Just look at the garbage fire which is the standard library. qsort. strtok. rand.

C++ should (in theory at least) be able to match or surpass C for _any_ performance benchmark, because it simply gives you more tools in your toolbox. For example, C is never going to be able to beat std::sort because it can't monomorphize in the compare function.

I'm not saying C++ is perfect either (looking at you unordered_map and regex). But I am saying people look at C with rose colored glasses.

Re: C++ Should Be C++

#98

Post by CoolGuySteve »

MaxBarraclough wrote: post #93
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…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

No, C is not the same as it is less expressive.

C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros.

See elsewhere in this thread for discussion of boost, it's not applicable.

Re: C++ Should Be C++

#99

Post by josephg »

mxmlnkn wrote: post #51
moffkalast wrote: post #25

Earlier quoted context omitted.

I think it's less about not wanting memory safety and more that compilation speeds are so time-wastingly abysmal that it's a few orders of magnitude more important to address. The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.

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.

Re: C++ Should Be C++

#100

Post by throwaway81523 »

gafferongames wrote: post #95
MaxBarraclough wrote: post #93

Earlier quoted context omitted.

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers. Compile time would also be an exception.

I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.
Post reply on HN