The Time Needed to Write “Effective Modern C++” • Hacker News Board

Re: The Time Needed to Write “Effective Modern C++”

#121

Post by steveklabnik » Thu, Apr 23, 2015, 1:40 PM UTC

andrepd wrote: post #113

moomin wrote: post #93

Earlier quoted context omitted.

I think Rust is making the case that you don't. In particular, I think one of the largest sources of complexity is C++'s backwards compatibility.

Speaking of backwards compatibility, I much prefer C++'s overzealous stance over the instability and inconstancy of Rust that prevents it from being used in any serious work. This is okay, it's a beta. I'll reserve judgment on Rust for now. But Rust also introduces complexity, while improving substantially in many areas. Of course it will do things better than what a language initially designed decades ago will do. A…

22 days till 1.0...

> as performant as C++

LLVM helps a lot here. We're generally in the same order of magnitude, sometimes faster, sometimes slower. It depends, as always with performance.

> comparible number of libraries

Yeah, this is a big one. If those C++ libraries also expose a C interface, we have zero-overhead FFI, but not all of them do. Crates.io currently has 1,893 packages, with a million and a half downloads served so far. It's a start, but always a weakness of a young language.

> platform support

LLVM helps here too, though there will always be some embedded platforms and such that ship their own C or C++ compiler.

Re: The Time Needed to Write “Effective Modern C++”

#122

Post by kbart » Thu, Apr 23, 2015, 1:46 PM UTC

RBO2 wrote: post #104

kbart wrote: post #96

Earlier quoted context omitted.

A lot of people working with C/C++ I know are looking forward to Rust, but the problem is that currently it's nowhere near as mature and widespread as former languages. I hope that will change in the near future as it looks like promising system language.

Why wait for Rust when D is already there?

Honestly, I haven't tried D, but if it hadn't got traction in 14 years, I'd say it was a miss. It's not enough to be a good language -- documentation, tools, libraries, community, adoption in open source projects is, arguably, even more important.

Re: The Time Needed to Write “Effective Modern C++”

#123

Post by GFK_of_xmaspast » Thu, Apr 23, 2015, 1:48 PM UTC

AlexandrB wrote: post #109

kbart wrote: post #68

Earlier quoted context omitted.

Yeah, tell that to embedders and kernel/driver programmers.

The irony is that at least one class of kernel developers (Linux) refuse to touch C++.

Yeah, but how much of that is because Torvalds has opinions and how much of it is actual fact and preference.

Re: The Time Needed to Write “Effective Modern C++”

#124

Post by blt » Thu, Apr 23, 2015, 1:52 PM UTC

angersock wrote: post #50

blt wrote: post #44

I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!" for now, it seems that C is insufficiently expressive and everything else is too slow. but the complexity of C++ is troubling.

Everything else isn't too slow, though, especially if you hit any meaningful IO.

I work on programs that are CPU and memory access bound.

Re: The Time Needed to Write “Effective Modern C++”

#125

Post by GFK_of_xmaspast » Thu, Apr 23, 2015, 1:53 PM UTC

unstabilo wrote: post #56

angersock wrote: post #50

Earlier quoted context omitted.

Everything else isn't too slow, though, especially if you hit any meaningful IO.

Or if you use clever algorithms. I don't have benchmarks at hand, but I suspect that an FFT in Python is faster than a naive Fourier transform in C.

I think the replies to this post are getting confused between the FFT/DFT, which is O(n log n), and the "naive Fourier transform", O(n2).

My experience with numerics in regular python is that they're generally 50-500x slower than the equivalent in C/C++, this just pushes back the point at which the asymptotics take over.

Re: The Time Needed to Write “Effective Modern C++”

#126

Post by innguest » Thu, Apr 23, 2015, 1:59 PM UTC

restalis wrote: post #84

blt wrote: post #44

I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!" for now, it seems that C is insufficiently expressive and everything else is too slow. but the complexity of C++ is troubling.

"the complexity of C++ is troubling" This comes out of the fact that C++ is being developed more as an engineering tool than as a programming toy. When you're into real engineering, you don't have free lunch.

This is the attitude that keeps us mired in subpar ideas like C, C++, Java, HTML, CSS, JS.

"I'm a tough guy and tough guys use tools that make our lives hell! We're serious! We're engineers! Your language is just a toy because our managers want to keep us fungible!"

What does an average "real engineer" C++ programmer have at their disposal? C++ has an ersatz type system (not algebraic and not connected to type theory) and an ersatz macro system (templates and preprocessing) and it offloads type signing onto the programmer (no help from an inferencer). It also lacks a garbage-collector because its followers are still afraid of non-existing "performance penalties". C++ has an ambiguous grammar that is context-dependent and requires infinite lookahead. Its creator is not any revolutionary thinker like Alan Kay, just some guy that wrote a language and become famous for writing that language. He also said that we hear a lot of complaints about C++ just because a lot of people use it, not because it's crap.

But bullies like restalis rejoice in the fact that know-nothing managers keep choosing C++ because it's the industry bandwagon and you can count on universities to supply the market with a fresh load of programmers trained in mediocre tools time and again.

You're a bandwagoner.

Re: The Time Needed to Write “Effective Modern C++”

#127

Post by rprospero » Thu, Apr 23, 2015, 2:18 PM UTC

easytiger wrote: post #120

rprospero wrote: post #107

Earlier quoted context omitted.

I think the argument isn't that Python code out performs C code, it's that code written by mediocre Python programmers often outperforms code written by mediocre C programmers. C code is fast enough the mediocre programmers get used to letting the language bail them out. Python programmers know that their language is slow and that they have to work around it. I've encountered this several times in my own career. A co…

Makes literally no sense. The c developer would simply use the same c/fortran library the python implementation is based on. You are creating a false dichotomy for the sake of it.

The c developer should use the same c/fortran library that the python implementation is based on. A good C developer would use that library. In my experience, mediocre C developers will not use that library and will implement their own, naive version.

Re: The Time Needed to Write “Effective Modern C++”

#128

Post by netheril96 » Thu, Apr 23, 2015, 2:27 PM UTC

coliveira wrote: post #118

netheril96 wrote: post #74

Earlier quoted context omitted.

Most of the time `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. In addition, to enforce immutability in C++, you have to disable copy/move constructors and assignment operators, which removes much benefit of using values instead of references.

> `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.

> because it can be cast away so easily

By this logic, none of the static type checks in C++ is of any use, since they can be cast away easily as well.

Re: The Time Needed to Write “Effective Modern C++”

#129

Post by innguest » Thu, Apr 23, 2015, 2:30 PM UTC

solipsism wrote: post #14

rshaban wrote: post #9

Earlier quoted context omitted.

It would seem from the context of his statement the latter, especially given that he built C++

Creating C++ means you're likely to know the ins and outs of the language. That's a necessary condition to being a good C++ programmer, but it's not sufficient. It's not at all obvious to me that Stroustrup would be a good C++ programmer or even a good C programmer.

Macho man! If you need to know the intricacies of an abstraction in order to use an abstraction, then it's not a very good abstraction.

Do engineers know the ins and outs of concrete and rebar? Or do they offload that knowledge onto manufacturers? But programmers can't offload anything onto the language creator or they aren't real programmers.

I'm glad for all the work the SBCL and GHC teams put onto their languages so I can use their abstractions without needing to know the ins and outs of performance optimization. Maybe one day you'll find a language you like that allows you to focus more on your problem domain and less on its traps, idiossyncrasies and inadequacies.

Re: The Time Needed to Write “Effective Modern C++”

#130

Post by netheril96 » Thu, Apr 23, 2015, 2:32 PM UTC

coliveira wrote: post #114

lultimouomo wrote: post #78

Earlier quoted context omitted.

This does not seem like a strong argument. Yes, table salt is useful, but if you don't know what it actually does and you put it in your eyes, it will burn them, just like most, well, everything... A const reference guarantees to the caller that the callee won't modify the object, not to the callee that the object won't be modified.

Except that it doesn't. Thanks to const_cast, you can take away constness from pointers, so where does your "guarantee" comes from?

The guarantee is not against a malicious agent, but a reasonable programmer who may make mistakes.