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

201–210 of 243 posts

Re: Deep C and C++ (2011)

#201

Post by NAFV_P »

Suncho wrote: post #194

Most of the C stuff here is pretty good, but some of the C++ information is a little questionable. Even the "good programmer" exhibits a few common misconceptions about inheritance and virtual destructors. Here's the text from slide 348: "What is the point of having a virtual destructor on a class like this? There are no virtual functions so it does not make sense to inherit from it. I know that there are programmers…

"On the other hand, seeing the keywords "new" and "delete" in code is usually a bad sign." I thought those two keywords were intended to replace the basic memory allocation functions found in stdlib.h. What are the alternatives?

Re: Deep C and C++ (2011)

#202

Post by bjackman »

kyllo wrote: post #190
nraynaud wrote: post #48

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…

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 agree, and I'd add that C/C++ is a bit of a leaky abstraction layer over assembly. It aims to be portable, but true portability means that the C/C++ developer really shouldn't have to know/care what assembly in…

I've been spending a lot of time recently looking into and thinking about alternatives to C.

I'd love to see a language as close to assembly as C is, but with a cleaner disconnect with it. As an example of what I mean:

Bitfields would be really handy when writing a device driver. A basic example of the difference they would make is "if (reg.field == VAL)" vs. either "if (reg & MASK == VAL)" or "if (GET_FIELD(reg) == MASK)". But you can't use them for that purpose because their layout is implementation defined.

There would be a noteworthy performance benefit to pay for portable bitfields, but I think it would be worth it. Right now I have to write ugly code if I want any attempt at portability (always). I'd much rather have to write ugly code where I need speed (sometimes).

I'd love to hear if anyone else has any ideas on this matter (BTW it seems like D solves many of the problems I've been thinking about, but it's memory managed).

Re: Deep C and C++ (2011)

#203

Post by hackinthebochs »

Suncho wrote: post #194

Most of the C stuff here is pretty good, but some of the C++ information is a little questionable. Even the "good programmer" exhibits a few common misconceptions about inheritance and virtual destructors. Here's the text from slide 348: "What is the point of having a virtual destructor on a class like this? There are no virtual functions so it does not make sense to inherit from it. I know that there are programmers…

What would a resource management class look like?

Re: Deep C and C++ (2011)

#204

Post by blt »

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

Scheme has a bit of flavor of the "inevitable" to me...

Re: Deep C and C++ (2011)

#205

Post by boryas »

NAFV_P wrote: post #201
Suncho wrote: post #194

Most of the C stuff here is pretty good, but some of the C++ information is a little questionable. Even the "good programmer" exhibits a few common misconceptions about inheritance and virtual destructors. Here's the text from slide 348: "What is the point of having a virtual destructor on a class like this? There are no virtual functions so it does not make sense to inherit from it. I know that there are programmers…

"On the other hand, seeing the keywords "new" and "delete" in code is usually a bad sign." I thought those two keywords were intended to replace the basic memory allocation functions found in stdlib.h. What are the alternatives?

make_shared and make_unique http://herbsutter.com/gotw/_102/

Re: Deep C and C++ (2011)

#206

Post by eruditely »

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.

That standard is too arbitrary and stringent.

Re: Deep C and C++ (2011)

#207

Post by blt »

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…

I wish ++ didn't exist. It's a waste of mental energy.

Re: Deep C and C++ (2011)

#208

Post by blt »

NAFV_P wrote: post #200
xradionut wrote: post #176

Earlier quoted context omitted.

You need to learn the history of HN and realize that Lisp is the original hacker language. As for assembly, there's been several lists of "free" computer books post that have included assembly tutorials.

"You need to learn the history of HN and realize that Lisp is the original hacker language." That's fairly common knowledge, I've been coding for eighteen months and I learned that "fact" months ago. "As for assembly, there's been several lists of "free" computer books post that have included assembly tutorials." I haven't mentioned what assembly I wish to learn. A lot of the assembly tutorials I have found on the we…

I would recommend the CS 61C course videos from Berkeley: http://www.youtube.com/playlist?list=PL01C2A0DE46A54CA9

It uses MIPS assembly, which you can run on a simulator. I don't think many machine architecture classes teach x86 because it's more complex. The MIPS knowledge from that course has translated easily to x86 in my tiny experience of peering into my compiler's assembly output.

Re: Deep C and C++ (2011)

#209

Post by jgreen10 »

dman wrote: post #175
jgreen10 wrote: post #59

Earlier quoted context omitted.

I didn't have any trouble with the C examples, but with C++ it just puzzles me why people would want to use a language like that in the first place. What does it buy you except bigger head aches?

RAII.

You don't need RAII if you don't have exceptions. Separating allocation and initialization is a good thing.

Re: Deep C and C++ (2011)

#210

Post by dman »

jgreen10 wrote: post #209
dman wrote: post #175

Earlier quoted context omitted.

RAII.

You don't need RAII if you don't have exceptions. Separating allocation and initialization is a good thing.

RAII is used for idiomatic cleanup from a function. In C the way to handle that would be to have a cleanup section in every function and then doing a goto to that which adds clutter to the function.
Post reply on HN