Live data from Hacker News

Deep C and C++ (2011)

slideshare.net

141–150 of 243 posts

Re: Deep C and C++ (2011)

#141
post #97

Earlier quoted context omitted.

It's real, it's called the Dunning-Kruger Effect. I've seen it plenty of times with real superstar-experts rate themselves as "slightly above average"... http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

I think it is more than that. I had a boss that basically would not hire somebody if they said they were at the top of any measure. In one sense, she was correct. No one can know everything about C++. OTOH, if you are in the 9x percentile, why should you not rate yourself at 9-10 out of ten? At some point it gets silly when you are arguing about how you should properly distribute yourself in bins so long as you under…

I think there are actually 2 questions:

Among professional programmers, at what percentile are you, in terms of C++ knowledge?

Of all there is to know about C++, how much (in%) do you know?

Your answer will depend a great deal on which question you believe this is about.

Re: Deep C and C++ (2011)

#142
Informative and thought-provoking presentation, but I think the mock interview format is a disservice, as with it comes individual ideas of what a good or useful interview is like.

Re: Deep C and C++ (2011)

#143
post #130

Earlier quoted context omitted.

There are two legitimate concerns in a debug context. The first is predictability / repeatability; zeroing is substantially more helpful than randomization in this context. The second is revealing incorrect assumptions / fuzzing / stress testing; zeroing is substantially less helpful than randomization in this context. Ideally, both options would be available. When someone says "give me a debug build", I think it's p…

Predictability and randomization are not mutually exclusive, you only need a way to specify the seed for the PRNG used during randomization.

No, that addresses reproducibility, which is worthwhile but is not the same as predictability.

Predictability in this context means simplifying the problem. If uninitialized memory is nulled, then I know what I'm looking for/at more quickly. Likewise if it's set to any other particular, known value. I know it will (or won't) be failing null checks, and I know that it will (or won't) be segfaulting if dereferenced. This helps with characterizing and fixing bugs, (related to but distinct from detecting bugs in the first place). Relying on this to make the program work is bad, but that's not the same thing.

Re: Deep C and C++ (2011)

#144
post #45

Earlier quoted context omitted.

>In an interview, I would much rather hear a person say something about a statically declared variable with no initialization being poor code to leave behind for the next person than some arcana about the standard. Why are you forcing those two choices? One could be well-versed with the arcana AS WELL AS point out that bit about statically declared variable .. The problem IMO is most programmers cargo-cult/copy-paste…

> Great mathematicians can understand the theory and just apply it to whatever problem they come across. As someone who's both a mathematician and a programmer, I think that analogy glosses over an important difference, which is also relevant to why many people refuse to memorize certain things. Good mathematical theories are internally consistent in a very strong sense. When you're learning them, you feel like you'r…

Mathematicians tend to miss one important ideal; a major consumer of your code needs to be other programmers who read it. Hence why mathematicians often end up writing code that, while more terse, is a jumbled mess of single letter variables and layered abstractions.

Re: Deep C and C++ (2011)

#145
post #97

Earlier quoted context omitted.

It's real, it's called the Dunning-Kruger Effect. I've seen it plenty of times with real superstar-experts rate themselves as "slightly above average"... http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

I think it is more than that. I had a boss that basically would not hire somebody if they said they were at the top of any measure. In one sense, she was correct. No one can know everything about C++. OTOH, if you are in the 9x percentile, why should you not rate yourself at 9-10 out of ten? At some point it gets silly when you are arguing about how you should properly distribute yourself in bins so long as you under…

The only problem with that is that you have no way of knowing what kind of scale adjustments they are using.

http://hyperboleandahalf.blogspot.no/2010/02/boyfriend-doesn...

Re: Deep C and C++ (2011)

#146

this has nothing to do with understanding but more with memory. What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of information (it is reflected on the size of the specs). There is also the fact that very often non-specified behavior, or implementation dependent or everything else that is not cool does not lead to a wa…

This has nothing to do with understanding but more with memory. What's drowning people in C and even more in C++ is not the logic of the language, but the sheer number of tricky concepts and the pure accumulation of information (it is reflected on the size of the specs).

I've been coding C++ for a few years now and it still baffles me most of the time. If I take a break from it for a bit, I have to re-learn how pointers function every time.

Re: Deep C and C++ (2011)

#147

I love this presentation. It led me to read Expert C Programming [1] by Peter Van Der Linden. My knowledge of C had vastly improved after reading that book (and subsequently C++). Even if you're not a C programmer I would recommend the book as the anecdotes alone are worth reading for the questions that it encourages you to ask. I've since come to believe that reading the specifications and having the attention neces…

It's wonderfully frustrating that there is truly so much to learn that even the study of programming languages, which is an incredibly tiny field relative to the whole of human knowledge, it is still necessary to make depth vs. breadth trade-offs. I find your choice to focus more on depth appealing, but almost immediately feel a sense of loss for all the breadth such a focus would require giving up.

I think a better balance may be to master things that are widely relevant at depth, while giving less focus to things that are very specific. Put another way: depth for "essence", breadth for "accident". Of the items on slide 181 of the presentation, only calling conventions, memory model, and probably optimization seem like "essence" to me, ie. every program you ever write in any language will benefit from deep knowledge of those topics. The rest of the items are somewhat arbitrary and very specific to the particular history of the C language itself.

Re: Deep C and C++ (2011)

#148

Earlier quoted context omitted.

Why on Earth are you writing a statement like that in the first place?

Exaggerated example to show a pattern. A (hopefully) less outrageous (but still bad!) example of the dangers of sequencing: foo(std::unique_ptr {new T1 }, std::unique_ptr {new T2 }); This one's from GotW #102.

Thanks. Just read the GotW.

http://herbsutter.com/gotw/_102/

Re: Deep C and C++ (2011)

#149
post #29

Earlier quoted context omitted.

I couldn't find that link, could you share it please? Thanks in advance.

Try using hnsearch, it's little publicised but very useful! A search for math (it's the 'Dear Startups... ' link): https://www.hnsearch.com/search#request/all&q=math&start=0

Thanks, I thought his quote was a string literal so a search with that yielded no results.

Re: Deep C and C++ (2011)

#150
You know if someone's asking me these kinds of questions in an interview it's the sign that something's deeply dysfunctional on the team and there's been some kind of past trauma that makes them feel the need to ask.

That or they're assholes.

Either way, walk.

Post reply on HN