Live data from Hacker News

Deep C and C++ (2011)

slideshare.net

121–130 of 243 posts

Re: Deep C and C++ (2011)

#121
post #116

Earlier quoted context omitted.

My comment was talking about a stronger kind of consistency, maybe "inevitability" would be a better word for it. You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.) You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict t…

>You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict the n+1st. You're mis-applying things here. The language is not something to be theorized by itself. Like any (edit:spell) other body of knowledge, it has its own set of initial axioms and the 'C standard' which defines the language is simply a collection of rules other meta-knowledge which are based on…

Yes, you could say that the C standard is a formal theory. It won't be a very interesting one to a mathematician though, because it's huge and describes only one thing, C. There are no special considerations to single out that theory from a huge pool of similar ones. It's like devoting your life to the study of one particular differential equation with a thousand terms, which was written by a committee. Why not the other equation which has a minus instead of a plus over there? Why not study differential equations in general?

Compare with a formal theory like PA, which fits on a page and describes the natural numbers. Proving a theorem about PA has implications everywhere, because natural numbers are everywhere. Or if we want to talk about computation, there are many formal theories with short descriptions that have much more to say about computation in general.

Re: Deep C and C++ (2011)

#122
post #58

A fun fact about sequence points. C++ has switched from "sequence points" to "sequenced before/sequenced after" relation. And it is not really "all" previous side-effects that are guaranteed to be visible after the sequence point but only those associated with the sequence point. In 'foo(b++, a++ && (a+b));' the sequence point introduced by the '&&' only makes the 'a' see the effect 'a++' but the 'b' might not see th…

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.

Re: Deep C and C++ (2011)

#123
post #116

Earlier quoted context omitted.

>You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict the n+1st. You're mis-applying things here. The language is not something to be theorized by itself. Like any (edit:spell) other body of knowledge, it has its own set of initial axioms and the 'C standard' which defines the language is simply a collection of rules other meta-knowledge which are based on…

Can you deduce the majority of the C language from these initial axioms? You misunderstand the usage of consistency regarding mathematics. It is not the same. These rules which compose C are design decisions, and whether they are entirely artificial. Mathematical consistency arises from imposing axioms, following which there are no decisions to be made.

>Can you deduce the majority of the C language from these initial axioms?

Well, no. You can deduce A language but it might not be C.

I sense we're going down a fruitless path here. In my first post I was only giving an analogy of someone understanding math at a fundamental level to someone understanding a programming language at a fundamental level and how they could inform similar abilities/prowess in people when it comes to dealing with complex problems/etc.

Re: Deep C and C++ (2011)

#124

A college student in CS here. I'm always impressed by people with deep understanding of programming language internals and try to pick up as much about programming language internal workings and compilers as I can. How does one get really good at this? Is it by spending a lot of time programming and building stuff? Is it by reading books/blogs/articles about programming languages? Any recommendations for such resourc…

Everyone else's advice to learn by doing is great, but there is also _Expert C Programming_ by Peter van der Linden: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp... The presentation's "Deep C" pun is a reference to this book, and if you make it all the way to slide 444 you'll see it mentioned as further reading. It's a wonderful book for understanding C (not C++) and what's really going on.

It'll take a team of ten authors and a couple of decades to write something of that kind for C++.

Though the language is full of horrors, I still quite enjoy C++ (esp. with C++11 and am looking forward to some C++14 features...)

Re: Deep C and C++ (2011)

#125
I wonder what a linux kernel developer would have to say about these slides. How many of these features/quirks are they finding useful in their day to day job.

Re: Deep C and C++ (2011)

#126
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…

> 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 .. You're the one forcing the choices. He's just saying that one should consider another metric to gauge developers, that is knowledge of good software practices over deep language arcana wisdom. And he's saying that whatever the knowledge depth (or lack of) of a candidate…

>You're the one forcing the choices.

"I would much rather [a person do X] than [a person do Y]"

I parse this kind of statement as a person doing X is more important than a person doing Y. I stated that I thought both were achievable. How have you parsed it?

Also trivia implies some memorized factoids. The entire point of the article is having an understanding of the underlying implementation of the compiler, maybe the implementation of the standard library, or the OS or the hardware ADDS to your knowledge about C making you a much more complete/well-rounded developer. Calling it C trivia is baffling to me.

>Life is too short to become an expert on C's dark corners, and I'm not even talking about C++'s.

Agreed !

Re: Deep C and C++ (2011)

#127
post #99

Earlier quoted context omitted.

No, I too am talking about a hierarchy of internally consistent knowledge. Have you implemented a compiler or a interpreter for a popular language? I could be wrong but I strongly suspect you haven't. If you have ever implemented a compiler you understand the language at a fundamental level and when stumped with a bug or a highly technical puzzle or what have you - you get that "aha" moment where its like "Ofcource !…

My comment was talking about a stronger kind of consistency, maybe "inevitability" would be a better word for it. You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.) You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict t…

My guess you apply your experience with some bizarre language (PHP?) to C, which you never learned. C and C++ are internally consistent in the same way a math theory is. Many programming languages are not, indeed.

> You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.)

Coincidentally, same is Math. I give you Euclid's Fifth postulate as an example.

>You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict the n+1st.

This depends on how do you enumerate these rules. If you learn that auto variables are allocated on the stack it's easy to predict that you cannot return their addresses and there are not going to be default initializes for them.

Re: Deep C and C++ (2011)

#128
post #116

Earlier quoted context omitted.

>You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict the n+1st. You're mis-applying things here. The language is not something to be theorized by itself. Like any (edit:spell) other body of knowledge, it has its own set of initial axioms and the 'C standard' which defines the language is simply a collection of rules other meta-knowledge which are based on…

Yes, you could say that the C standard is a formal theory. It won't be a very interesting one to a mathematician though, because it's huge and describes only one thing, C. There are no special considerations to single out that theory from a huge pool of similar ones. It's like devoting your life to the study of one particular differential equation with a thousand terms, which was written by a committee. Why not the o…

I am not against your POV ! I think we largely agree on most things here. I wanted to correct what I perceived to be a mischaracterization of my 'off the cuff' analogy.

Re: Deep C and C++ (2011)

#129
post #43

Earlier quoted context omitted.

Totally disagree with this. I've worked with plenty of fantastic programmers who are basically worthless without the guidance of a good lead/producer/designer. Nonobligatory image to support statement: http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0128776...

That gui seems fine to me. It's ugly as sin, sure, but it has everything easy to find and clearly labeled. Ignore the parts you aren't using and you're good to go.

Ehhh. I'm not so sure about setting the depth for recursive retrieval to zero. That's basically telling wget to download the internet IIRC :D

Re: Deep C and C++ (2011)

#130
post #101

Earlier quoted context omitted.

You have printf, and the interviewer says "on my machine, I actually get 1, then 2, then 3". Those two hint very strongly at a general purpose computer, thus paging etc. What really annoyed me is the suggestion that zeroing is more helpful than randomization in a debug context. Randomizing everything not defined by the standard is a good way to trigger lots of bugs based on false assumptions...

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.
Post reply on HN