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

Deep C and C++ (2011)

slideshare.net

Post reply on HN
Print view View original

111–120 of 243 posts

Re: Deep C and C++ (2011)

#111

Post by userulluipeste »

glormph wrote: post #38

I only know python well and am looking for another language to learn. C was on the shortlist, but after this, crikey. At least I now know it's not going to be an easy ride.

I found the original ANSI C to be more straightforward, and many times after I was asking myself "why was this done in this way" I only realized that I would have ended up with the same way of doing things - e.g. that the stack arrays should just skip the "pointing" memory, and things like that. What you saw in the presentation are mostly just later complications that popped up from the attempt to improve the manner of approach while keeping the entire thing speedy and backward-compatible. Do you think this is too much? Take a look at C++11 and marvel at the quantity of language hacks there!

Re: Deep C and C++ (2011)

#112

Post by ksk »

kamaal wrote: post #84
pjmlp wrote: post #51

Earlier quoted context omitted.

> You'll find them toiling away in anonymity, working in research labs, working on compiler optimizers or operating systems or some other domain with challenging technical problems. Sadly you are required to move for such jobs, which is not always an option.

And best of all is such things are not fashionable. Take a round of HN or any other place where programmers hang around. Take a note of how many articles, blogs posts, essays, tiny libraries, frameworks etc are written for languages like Javascript, or Python, or Ruby, or Java. Compare this with C. There is a degree of serious technical focus that languages like these demand for big projects. Embedded systems, Operat…

I don't know why you have C up on some pedestal. Its not really a 'hard' language to learn or grasp.

Sure some languages take less time to learn than others. But every single language makes tradeoffs. For e.g performance vs productivity/usability OR static typing vs dynamic typing is a common theme when discussing C vs {Java, Python, blah}.

Also, your comments falsely compare the difficulty of the TASK with the difficulty of the IMPLEMENTATION/LANGUAGE. They are not the same! Take any advanced applied math algorithm and implement it in Python. Its not 'easy' by any means.

The domains you mentioned have a higher barrier to entry because the tasks themselves are difficult. The languages and technology used are simply variables in a much larger optmization problem that also includes monetary/human/computing/time resources as variables.

Re: Deep C and C++ (2011)

#113

Post by dllthomas »

I'm not sure "provide only one way of doing things" is a core principle of C. It at least seems to have fallen to "type less" in several cases:

    i = i + 1;
    i += 1;
    i++;
    ++i;

    a[i]
    *(a + i)

    a->foo
    (*a).foo

Re: Deep C and C++ (2011)

#114

Post by epsylon »

ksk wrote: post #45
hacknat wrote: post #7

I'm not so jaded as to think that deep language understanding isn't a useful or good thing, and I'd like to think I have some myself. However, deep language understanding is not what separates the great engineers from the good ones. 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…

>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 on the C or C++ language, he'll choose the one with better software practices. (Of course, the two metrics are slightly correlated, but being an expert on C trivia doesn't necessarily makes you a good developer)

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

Re: Deep C and C++ (2011)

#116

Post by ksk »

cousin_it wrote: post #104
ksk wrote: 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…

>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 those. In that sense it is internally consistent. Thats what I meant.

Re: Deep C and C++ (2011)

#117

Post by ben0x539 »

coldpie wrote: post #105
praptak wrote: 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?

It's probably less about writing the statement while cackling maniacally and more about recognizing that pattern in less obvious examples in existing code while reviewing it or looking for a bug, and realizing that it might be worth investigating and not just a style nitpick.

Re: Deep C and C++ (2011)

#118

Post by patrickmclaren »

ksk wrote: post #116
cousin_it wrote: post #104

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…

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.

Re: Deep C and C++ (2011)

#119

Post by ben0x539 »

jmgao wrote: post #25
aidenn0 wrote: post #4

Heh, and they didn't even get into the aliasing rules. In embedded software, life would be a lot easier if I could hit every engineer who wants to type-pun without a union in the head with the ISO standard. For this reason, a lot of compilers have options to not strictly enforce the aliasing rules [edit] Also C and C++ are both permitted to reorder structs, it's just that they don't because that's the easiest way to…

As mentioned by others, C does not allow reordering of members in structs. However, C++ does! §9.2.12 says: Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1) This means, that under a strict…

Did this change in C++11 or does this wording mean the same thing? It's not clear to me that the implicitly public a is of a different access control than the explicitly public b according to the following wording:

> Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified (11).

Re: Deep C and C++ (2011)

#120

Post by Romoku »

smnrchrds wrote: post #82
Negitivefrags wrote: post #69

Earlier quoted context omitted.

Would you only consider someone's knowledge of Python a 10 if they could write a Python interpreter without guidance?

I will give the creators of PonyORM a 10 as well. http://stackoverflow.com/questions/16115713/how-pony-orm-doe...

It's really quite interesting that they build the queries from the AST. To contrast C# generates the Sql for Linq to Sql by building up an expression tree using the IQueryable interface.

This simplifies step one of the Pony ORM author's answer.

Post reply on HN