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

161–170 of 243 posts

Re: Deep C and C++ (2011)

#161

Post by deckiedan »

dmak wrote: post #149
nilliams wrote: post #57

Earlier quoted context omitted.

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.

Sorry dmak - I guess quotes are easily misunderstandable for us programmer types. Maybe we need a comments quoting system:

- 'string literal quotes' - "inexact quotes which ${evaluate things}" - `ticked off sarcastic quotes (quoting someone back at themselves)` - quoted comments by oldschool BBS junkies

:-)

Re: Deep C and C++ (2011)

#162

Post by Too »

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…

Embedded C developers can produce very, ehum, 'interesting' code. They usually come from electronics engineering and think in terms of registers and memory instead of an abstract machine. I've seen code that actually relies on two arrays being defined in order and thus can be indexed from only the first array but with a calculated offset. This is outside of a struct...

Just type casting a struct to a char-pointer and dumping it straight out on the network or to persistent storage is code you see every day.

Re: Deep C and C++ (2011)

#163

Post by Bill_Dimm »

brohee wrote: post #101
RogerL wrote: post #95

Earlier quoted context omitted.

Okay, you are assuming an Intel architecture? Plenty of embedded environments don't have OSes, let alone pages or virtual memory. IOW, I've worked in environments where, yes, the value in memory is based on what the compiler does in debug mode, not what the OS might be doing. I'd say the girl's answer is, while not exhaustive, certainly correct. Without more context, we don't know why the value was 0.

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

Slide #4 says: "Suppose you are about to interview a candidate for a position as a C programmer for various embedded platforms..."

Re: Deep C and C++ (2011)

#164

Post by Dylan16807 »

aspensmonster wrote: post #129
Dylan16807 wrote: post #98

Earlier quoted context omitted.

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

The entire domain. Reasonable use case.

Re: Deep C and C++ (2011)

#165

Post by xixi77 »

acron0 wrote: post #43
ateevchopra wrote: post #14

Earlier quoted context omitted.

Exactly. Deeper you go, better you are. Better you are, better products you make. Just Simple mathematics.

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

I love this GUI. Gives a clear view of what can be changed, and so much more user friendly than having to remember where each of the nested (often so many times!!) options goes. "Advanced..." buttons everywhere are the worst, and don't get me started about wizards.

Re: Deep C and C++ (2011)

#166

Post by pcwalton »

saejox wrote: post #73

All of the quirks listed have good reasons to exist. Except size_t, that never makes sense.

I don't agree. Just a few slides in, what good is "functions don't have to return a value explicitly, even if declared as returning non-void" (a priori, I mean—not counting backwards compatibility as a reason)?

Re: Deep C and C++ (2011)

#167

Post by cousin_it »

alexk7 wrote: post #136
cousin_it wrote: post #87

Earlier quoted context omitted.

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

Standard mathematical notation is not inevitable and is not unique. It is on par with most programming languages for being quite random. Both programmers and mathematicians use an imperfect tool (programming language, mathematical notation) to achieve goals that may, or may not, be eternal.

That's a fair point, and math notation is famously more ambiguous than programming languages. But it seems to me that the concepts denoted by math notation (e.g. numbers, arithmetical operations, functions...) are inevitable and unique, while the concepts denoted by strings in a programming language are much fuzzier and more arbitrary (except for languages that have a denotational semantics, which are few and far between).

Re: Deep C and C++ (2011)

#168

Post by pandaman »

pessimizer wrote: post #157
pandaman wrote: post #139

Earlier quoted context omitted.

>I think the point was that mathematics relies on a small set of postulates from which you can derive everything else. And I agree, this is one of the assertions my opponent has made. I did not go to refute it because, if not outright false, it's disingenuous. >Another way to put it is, learning the postulates for langx doesn't provide enough value for many to be worth doing. This is also true, same goes for everythi…

Trying to derive C from its postulates is like trying to derive 70s television from its postulates. Most of C is an accident of history.

I am not sure what is your point now. Are you aware that most of the math is way older than C?

Re: Deep C and C++ (2011)

#169

Post by NAFV_P »

pessimizer wrote: post #160
NAFV_P wrote: post #154

I signed up with HN to get articles related to C, yet they're about as common as hens teeth. I've just executed a word search on this comments page: 18 instances of "static", but no mention of "volatile" or "extern", which is the same situation in several textbooks on C. The article mentioned looking at the assembler output of a program, but didn't give any hints on where to learn some assembly.

I've noticed that the internet contains information about various assembly languages. I would suggest googling for their manuals.

It is tutorials that are required for learning, manuals are for people who are already proficient.

Re: Deep C and C++ (2011)

#170

Post by xradionut »

pjmlp wrote: post #60
xerophtye wrote: post #17

Earlier quoted context omitted.

Yep, with C and C++ , you can't really say you are an expert.

That is the same with any language. An expert should not only know the language as defined by the standard or canonical implementation, but also the majority of implementations for the said language and consequent deviations from the official language semantics. Ergo, no one is actually a real expert in a specific language.

Kay is an expert in Smalltalk and Wirth is an expert in Oberon.

Stroustrup is an expert at nailing legs to a dog and calling it an octopus.

Post reply on HN