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

181–190 of 191 posts

Re: C++ Should Be C++

#181

Post by JohnFen »

carlmr wrote: post #152
JohnFen wrote: post #113

Earlier quoted context omitted.

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.

That's fine and dandy as long as you don't use C++ with templates and other stuff that needs 90% of the code to be in the headers. Any recompile triggers a lot of recompilation. And no, I can't change the code the other hundred devs are writing in my company. In C++ there is no individual units. In C it's somewhat plausible with some discipline.

yes, that's why I used the disclaimer "as long as I can compile individual units and link them".

The problem with C++ templates is accurate, and is one of the several reasons why I avoid using templates in my own C++ code. I don't have that freedom in the code I write for my employer, though.

> In C++ there is no individual units.

Yes, there are. Those unit boundaries are often blurred by other C++ features, but they do exist.

Re: C++ Should Be C++

#182

Post by JohnFen »

eviks wrote: post #149
JohnFen wrote: post #111

Earlier quoted context omitted.

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

But the level of damage can be reduced by language choice

Maybe, but surely the better answer is for devs to do better.

Re: C++ Should Be C++

#183

Post by MaxBarraclough »

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.

Even there, you can use a subset of C++ and get pretty good compile times. Worse than C, as you're still dragging around the full weight of a C++ compiler, but still.

Re: C++ Should Be C++

#184

Post by bsder »

fluoridation wrote: post #168
bsder wrote: post #136

Earlier quoted context omitted.

> 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. Sort of. The primary issues are: 1) The C/C++ grammar is garbage. Note that every single modern language has grammatical constructs so that you can figure out what is "type" and what is "name" without parsing the universe. "typedef" makes that damn near impossible in C without pars…

1. No, the grammar is not the issue per se. As you say, C has the same problem, and C code invariably compiles dozens of times faster than C++, and both Zig and Rust have modern grammars, but Zig compiles about as quickly as C and Rust is only somewhat faster than C++ (depending on features used). 2. This is incorrect. What's happening is that each template instantiation for a new set of template arguments requires r…

> 1. No, the grammar is not the issue per se. As you say, C has the same problem, and C code invariably compiles dozens of times faster than C++, and both Zig and Rust have modern grammars, but Zig compiles about as quickly as C and Rust is only somewhat faster than C++ (depending on features used).

Sorry, the C++ grammar is terrible. There are lots of things where C++ can't figure out whether something is a class or name or template or constructor call until looking way far down the chain.

However, you are the first person I think I have ever heard claim that Rust is faster than C++. Rust is notoriously slow to compile.

Zig generally compiles much faster than most C projects I've used. However, that is difficult to lay at the hands of C as a lot of those are the build system being obtuse.

Re: C++ Should Be C++

#185

Post by dataangel »

zozbot234 wrote: post #92
dataangel wrote: post #87

Earlier quoted context omitted.

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

> Not so, unsafe code still has restrictions in Rust due to pointer provenance.

That's separate from what I'm referring to. In C++ a float* and an int* can never alias. In Rust f32* and u32* are allowed to. Meaning in a situation where whether they can alias can't be established by provenance (e.g. in a separately compiled function where the compiler at compilation time can't tell where the float and int came from) then C++ is able to use types to rule out aliasing, but Rust cannot.

Re: C++ Should Be C++

#186

Post by chris_wot »

chris_wot wrote: post #82
andrewmcwatters wrote: post #75

Earlier quoted context omitted.

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

Sorry, not STL, I meant the standard C++ library.

Edit: send an email to news@ycombinator.com

Re: C++ Should Be C++

#187

Post by fluoridation »

bsder wrote: post #184
fluoridation wrote: post #168

Earlier quoted context omitted.

1. No, the grammar is not the issue per se. As you say, C has the same problem, and C code invariably compiles dozens of times faster than C++, and both Zig and Rust have modern grammars, but Zig compiles about as quickly as C and Rust is only somewhat faster than C++ (depending on features used). 2. This is incorrect. What's happening is that each template instantiation for a new set of template arguments requires r…

> 1. No, the grammar is not the issue per se. As you say, C has the same problem, and C code invariably compiles dozens of times faster than C++, and both Zig and Rust have modern grammars, but Zig compiles about as quickly as C and Rust is only somewhat faster than C++ (depending on features used). Sorry, the C++ grammar is terrible . There are lots of things where C++ can't figure out whether something is a class o…

>Sorry, the C++ grammar is terrible.

When did I say otherwise? What I said was that it's not the main cause of C++'s long compilation times. The grammar causes other problems, such as making it more difficult to write parsers for IDEs, and creating things like the most vexing parse.

>However, you are the first person I think I have ever heard claim that Rust is faster than C++. Rust is notoriously slow to compile.

It's kind of a mixed bag. Given two projects of similar complexity, one in C++ and one in Rust, the one written in Rust will take longer to compile if organized as a single crate, because right now there's no way to parallelize compilation within a single crate. However, compiling the C++ version will definitely be the larger computational task, and would take longer if done in a single thread. Both contain Turing-complete meta-languages, so both can make compiling a fixed length source take an arbitrarily long time. Rust's type system is more complex, but I think C++'s templates win out on computational load. You're running a little dynamically typed script inside the compiler every time you instantiate a template.

Re: C++ Should Be C++

#189

Post by iFreilicht »

JohnFen wrote: post #182
eviks wrote: post #149

Earlier quoted context omitted.

But the level of damage can be reduced by language choice

Maybe, but surely the better answer is for devs to do better.

That actually seems unrealistic to me. Of course, people will always become better at doing the things they do, and we can always try harder, but many of these issues take time to consider and find during code reviews, and a few just slip by. That's why tools like Coverity exist, but you have to spend time and money to set those up, meaning it's only done when absolutely necessary (or one dedicated person is really pushing for it). Choosing a different language is basically free in the beginning, and it will impact which sort of bugs will be caught by default and which won't. C++ is also massively hurt in this regard by not having a package manager. JS is a very risky language by default, but a few tools just with their default settings will already help massively. I guess Nix could be considered the missing package manager for C and C++, but it's still niche and definitely not a "default" like pip, npm or cargo.

Re: C++ Should Be C++

#190

Post by carlmr »

penguin_booze wrote: post #178
carlmr wrote: post #152

Earlier quoted context omitted.

That's fine and dandy as long as you don't use C++ with templates and other stuff that needs 90% of the code to be in the headers. Any recompile triggers a lot of recompilation. And no, I can't change the code the other hundred devs are writing in my company. In C++ there is no individual units. In C it's somewhat plausible with some discipline.

> In C++ there is no individual units There's a still a notion of the compilation unit, which is the cpp file on which you invoke the compiler. Due to templates being prevalent in C++, included files contain the implementation as well; so any changes you make there lead to re-compiling a lot more compilation units than, for example, in C.

That is kind of restating my point. There might be these translation units, but they're tightly coupled to all the other translation units, making them not very individual IMO.
Post reply on HN