Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

scottmeyers.blogspot.com

Post reply on HN
Print view View original

101–110 of 152 posts

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

#101

Post by unfamiliar »

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.

I disagree. I see most of the complexity of C++ as being due to design mistakes which have to be maintained for backwards compatibility. I would personally like to see a breaking change where a lot of the inconsistencies and design mistakes that have been identified are rectified.

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

#102

Post by unfamiliar »

moomin wrote: post #93
andrepd wrote: post #81

Earlier quoted context omitted.

The price for zero-cost abstractions and expressiveness is a monstrous complexity. If you want clean, expressive and easy-to-write code, you have a ton of languages where you can do just that. If you want performance and expressiveness, you will have to do with C++'s complexity.

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.

I think Rust is going a pretty good job of adding a similar level of complexity. I see most of this due to the new abstractions they have added like lifetimes and borrowing. With the old abstractions we have kind of figured out the least confusing way to implement them.

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

#103

Post by w8rbt »

mpu wrote: post #5

Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not seem to apply his guidelines into any practical project of his. As a programmer, I'm suspicious when people have opinions and give advice but never showed me more than snippets of code. Like a master tailor that wouldn't sew. How come he gets that much recogniti…

Great programmers don't typically write books. They are busy writing programs. 'de Raadt on C' would be a good book, wouldn't it? But he'll never have time to write it.

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

#104

Post by RBO2 »

kbart wrote: post #96
seabee wrote: post #90

Earlier quoted context omitted.

You can see this with Rust which tries to satisfy the same niche. It's possible to avoid the gotchas in C++ while preserving the advantages, you just pay a different price by working harder to satisfy the compiler.

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?

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

#105

Post by dbaupp »

unfamiliar wrote: post #102
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.

I think Rust is going a pretty good job of adding a similar level of complexity. I see most of this due to the new abstractions they have added like lifetimes and borrowing. With the old abstractions we have kind of figured out the least confusing way to implement them.

I think initial impressions of Rust may make it seem a lot more complicated than it is. That's not saying it's simple, but it doesn't have the same kind of dark corners and 'surprising' interactions that has C++ (often due to backward compatibility requirements); most features in Rust are pretty orthogonal and minimal.

Having the compiler on your back about lifetimes/borrowing is definitely unfamiliar, but, fwiw, a programmer usually has to be keeping track of that in C/C++ anyway (if it's complex when the computer checks it, it's complex when a human checks it).

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

#106

Post by dbaupp »

GFK_of_xmaspast wrote: post #99
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.

One advantage of c++ is it is kind of nice to know that code you wrote six weeks ago is going to still work.

Yeah, instability is definitely a good reason for people to not use Rust, although that's quickly being resolved, both in theory, with the stable 1.0 release in just over 3 weeks, and in practice, with the recent 1.0-beta release.

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

#107

Post by rprospero »

easytiger wrote: post #71
chris_b wrote: post #66

Earlier quoted context omitted.

Because the FFT in python is almost certainly implemented in C, and probably more cleverly done than a naive FFT that I/you/someone would whip up as part of a C program.

Is this a joke? Something written with the same algorithm in c will be faster than python. Why not use someone elses non naive FFT impl in c then as well?

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-worker who writes in C will be implementing a process in parallel with my Python implementation. A week later, my O(N) Python code is outperforming my colleagues O(N^3) C code, since I chose a more complex algorithm which is trickier to get right. The C programmer then re-implements my method in C, which would completely trounce my own code, except I've spent that time leaning on BLAS and LAPACK, speeding up my operations again. The C programmer then starts using fast libraries instead of her own code, again beating my old source, only to find that I've now pushed a good chunk of the processing onto the GPU.

Eventually, I will run out of tricks. The final draft of the C code will trounce the final draft of my Python code. However, during most of the creation process, my Python usually out performs their C. Also, a truly talented C programmer would write my colleague's final draft as her first draft, negating every advantage that I had in the process. However, that's not a situation that I'm likely to run into, because places hiring truly talented programmers aren't likely to be hiring me.

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

#108

Post by ksherlock »

solipsism wrote: post #7
mpu wrote: post #5

Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not seem to apply his guidelines into any practical project of his. As a programmer, I'm suspicious when people have opinions and give advice but never showed me more than snippets of code. Like a master tailor that wouldn't sew. How come he gets that much recogniti…

Are you putting Stroutrup in the I'm suspicious of his advice category or the He teaches from experience category?

I'm suspicious of his advice because the c++ he wants isn't the c++ I want.

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

#109

Post by AlexandrB »

kbart wrote: post #68
angersock wrote: post #50

Earlier quoted context omitted.

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

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

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

#110

Post by AlexandrB »

tragomaskhalos wrote: post #98
dietrichepp wrote: post #88

Earlier quoted context omitted.

> I don't think its complexity is a problem. C++ is complex in many ways which are unrelated to its core functionality. For example: most vexing parse, integer promotions, conflated language features (classes provide records, polymorphism, namespacing, encapsulation), header files, vector , the grammar is insanely complicated, et cetera. C++, like Common Lisp, is a standards effort which places more value on preservi…

Well many of those issues are inherited from C, and Stroustrup has stated that compatibility with C was an absolute prerequisite otherwise C++ would have been stillborn. Given its position now, it's impossible to say that he was wrong, although I wonder if certain things could have been tidied up that would only have compilation-failed really bad code (e.g. it annoys me that you can pass a floating point value where…

While that's true, a lot of the complexity is self-inflicted. C++ tries to define syntaxes for its features in a C style which cripples a lot of features in unnecessary ways. For example, classes being kinda like a C struct instead of a separate syntax altogether.

Honestly, even Objective-C is better in this regard because the Objective-C parts are well separated from the C parts instead of feeling wedged-in.

Post reply on HN