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

111–120 of 191 posts

Re: C++ Should Be C++

#111

Post by JohnFen »

sakjur wrote: post #37
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…

That sentence stood out to me as well. I don't think C++ developers is necessarily the best people to ask when discussing whether memory safety is important and urgent to work on or not. A lot of developers are relatively shielded from the consequences of bugs and security vulnerabilities, either by their programs not being exposed to the wild in any major sense or by bureaucracy being in between them and any consequ…

> the deficiencies of a language becomes a concern for its end-users rather than its developers.

I think that this level of professional malpractice is something that can't be solved by language choice.

Re: C++ Should Be C++

#112

Post by josephg »

aw1621107 wrote: post #108
josephg wrote: post #99

Earlier quoted context omitted.

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 r…

> due to the fact that the linker needs to do extra work to eliminate redundant instantiations.

Yeah, I see this as another consequence of C++'s poor compilation model:

- Compilation is slow because a template class in your header file gets compiled N times (maybe with precompiled headers). The compiler produces N object files filled with redundant code.

- Then the linker is slow because it needs to parse all those object files, and filter out all the redundant code that you just wasted time generating.

Its a bad design.

Re: C++ Should Be C++

#113

Post by JohnFen »

moffkalast wrote: post #25
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 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.

I know I'm weird, but as long as I can compile individual units and link them to other already-compiled units then compilation speed is something I don't care about much at all.

Re: C++ Should Be C++

#114

Post by JohnFen »

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…

In the olden days, we always checked the compiler, libraries, and essential build tools being used into version control along with the code. That way you could always be sure that you could compile the code.

This stopped working so well with Windows, where you usually can't just copy executables out of version control and run them (you have to run an installer instead), but it still works pretty well for the Unices.

Re: C++ Should Be C++

#116

Post by stefan_ »

CoolGuySteve wrote: post #98
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…

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.

In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code?

"Zero cost abstraction" is a big fantasy. C++ is the king of hidden control flow and the costs are everywhere.

Re: C++ Should Be C++

#117

Post by gumby »

CoolGuySteve wrote: post #49
zozbot234 wrote: post #34

Earlier quoted context omitted.

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?

It depends on the contributors, but boost also almost always fails to consider performance implications. For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time. The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.

> For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time.

It’s also the opposite: a place where possible candidates for the standard get tried out first.

But like you, I rarely use it.

Re: C++ Should Be C++

#118

Post by einpoklum »

Kind of a weird paper.

1. It uses formalism to try to deny that there is some competition for brain-share and number-of-users among programming languages, or rather around the communities around programming languages.

2. It ignores how C++ has, multiple times, semi-reinvented itself rather than "being C++", spurred by features, idioms or use patterns in other languages, and even managed to mostly "eat their lunch", for better or worse (e.g. the D language).

3. A call for "aiming for coherence", while ignoring how it sometimes contradiction with other principles, such as: "What you don’t use, you don’t pay for" (the zero-overhead rule); and failure to argue even for a balance.

4. "In committee, we frequently spend time on things that only a small number of people care about." etc. etc.

Re: C++ Should Be C++

#119

Post by beautron »

professoretc wrote: post #74
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 d…

>> 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?

This isn't always true, and can't be generally expected, but I think it is true in the case of Go's standard libraries. These are high quality, and are one of my top examples of good, real source code to study (along with the DOOM and Quake source code). A nice touch in Go's library documentation is that you can click any API element (type, function, etc.) to be brought directly to its source code.

Yes, there are differences between writing libraries and writing programs. But there is value in studying well-written source code, even when it has concerns and requirements that differ from yours. You can adapt what you learn to your needs.

Re: C++ Should Be C++

#120

Post by einpoklum »

shortrounddev2 wrote: post #35
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…

It was my understanding that one can easily add their own allocator to any STL container, though as you point out you have to write that allocator yourself

Allocators have an inherently broken design, tying them to types. See this CppCon talk by the (engaging and funny) Andrei Alexandrescu:

https://www.youtube.com/watch?v=LIb3L4vKZ7U

std::allocator is to allocation what std::vector is to vexation (or: designing allocators that don't not-work)

Post reply on HN