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

11–20 of 243 posts

Re: Deep C and C++ (2011)

#11

Post by thepicard »

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…

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do.

A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example from the slides, the virtual destructor: making that class virtual when it shouldn't is a waste of CPU cycles _and_ bad documentation for future developers.

Re: Deep C and C++ (2011)

#12

Post by easytiger »

thepicard wrote: post #11
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…

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example…

In c and c++ understanding these things can save you 1 day a week on average.

Re: Deep C and C++ (2011)

#13

Post by deckiedan »

It is interesting looking at the 'deep' issues of programming languages. This kind of ties in with the "Don't ask me maths questions..." post a few days ago.

There really is a lot more to programming than just algorithms, UI design or syntax.

Re: Deep C and C++ (2011)

#14

Post by ateevchopra »

thepicard wrote: post #11
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…

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example…

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

Re: Deep C and C++ (2011)

#15

Post by jamornh »

thepicard wrote: post #11
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…

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example…

However, I'd be concerned that the person with strong understanding of things will simply leave uninitialized static variables lying around in the code simply because they _knew_ it was always initialized to 0. It might work if your entire coding team has that innate understanding, but that is unlikely.

Sometimes I think that having deep and expert understanding of a language may cause you to create code that other team members cannot understand... not on purpose, but due to your assumption that these are common knowledge (whether they should be or not isn't the issue.)

Re: Deep C and C++ (2011)

#16

Post by pjmlp »

easytiger wrote: post #12
thepicard wrote: post #11

Earlier quoted context omitted.

Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example…

In c and c++ understanding these things can save you 1 day a week on average.

I would say even more than that.

C and C++ can make someone loose days to track down issues, in this day and age, where teams are distributed with lots of offshoring and various skill levels across development sites.

My last C++ project was in 2006, since then I have only used C++ outside work. At work our focus has been in JVM and .NET languages.

I don't miss playing the C++ fireman expert role that has to fix a stability problem created by someone in the other side of the planet.

Re: Deep C and C++ (2011)

#17

Post by xerophtye »

pacaro wrote: post #9

I've been a C developer (among other things) for about 20 years or so, but I've always described my C++ skills as being "in the C with objects" range, I might have to change that to being "nearly in the C with objects" range.

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

Re: Deep C and C++ (2011)

#18

Post by raverbashing »

deckiedan wrote: post #13

It is interesting looking at the 'deep' issues of programming languages. This kind of ties in with the "Don't ask me maths questions..." post a few days ago. There really is a lot more to programming than just algorithms, UI design or syntax.

Yes, this worries me.

Especially today some people think "great programmers" are the ones who knows all the "fashionable" tools and frameworks, wants to abstract everything (god help him if he install vim in his test environment without a fab file that configures chef) and maybe worships Uncle Bob

Knowing how to use Redis is cool, do you know what's even cooler? Being able to write it (or at least knowing how it works more or less)

Re: Deep C and C++ (2011)

#19

Post by 0x09 »

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…

> Also C and C++ are both permitted to reorder structs, it's just that they don't because that's the easiest way to follow the standard.

Is that feasible? Doing so would require that the order of the member addresses not correspond to their layout in memory.

Post reply on HN