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

191–200 of 243 posts

Re: Deep C and C++ (2011)

#191

Post by pjmlp »

pkolaczk wrote: post #186
pandaman wrote: post #127

Earlier quoted context omitted.

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…

Saying that C++ is internally consistent at all is a huge exaggeration. Actually I'd be very careful with stating it is more consistent than PHP. Both have many sharp-edges and in both there are plenty of features that feel "tacked on" and are non-orthogonal to each other. E.g. why I can't make a generic (template) function virtual or why I cannot overload some overloadable operators to have exactly same semantics as…

In C++'s case "The Design and evolution of C++" is a good read to understand how the language turnout that way and why certain compromises were done.

Re: Deep C and C++ (2011)

#192

Post by kyllo »

pjmlp wrote: post #187
kamaal wrote: post #84

Earlier quoted context omitted.

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…

Small rant, so take it with a grain of salt. Personally I don't care about C, due to its unsafe by default design and my background in safer languages for systems programming. I got my first computer, a Timex 2068, at the age of 10. Spent two years mainly playing games and eventually started looking into programming. When I learned C, at the age of 16, I already knew BASIC (Spectrum, GW, Quick, Turbo), Assembly (Z80,…

Nowadays kids seem just to do JavaScript/Python/Ruby frameworks for generating web pages.

That's progress, IMHO.

Instead of distributing application binaries carefully targeted to each type of user machine, we only have to run the application on one server machine (or a cluster of them) in a central location and can serve the application over the network. We now have code-generating frameworks that help automate away much of the tedious, repetitive parts of implementing an application.

It's not a good thing that software development is hard. It does mean that you're a very smart and hard-working person if you're able to do it effectively. But it's not a good thing for society that you need to be so smart and hard-working in order to do it.

It is, however, a good thing that it's not as hard as it used to be. The fact that a software developer has to do and know less today than they did 20-30 years ago, just to build an application and distribute it to a large number of users, is a sign of progress.

Re: Deep C and C++ (2011)

#193

Post by pjmlp »

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…

It is a matter of community culture.

In the Pascal family of languages, developers tend to think first about having something working and then optimize if not fast enough.

In the C and C++ communities, developers tend to micro-optimize every line of written code, even before knowing if it makes sense to do so.

Re: Deep C and C++ (2011)

#194

Post by Suncho »

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 who do inherit from non-virtual classes, but I suspect they have misunderstood a key concept of object orientation. I suggest you remove the virtual specifier from the destructor, it indicates that the class is designed to be used as a base class - while it obviously is not."

She's right that the class described on the slide probably shouldn't have a virtual destructor.

A base class should have a virtual destructor if and only if objects of its derived class are to be deleted through base class pointers.

The following four statements are wrong:

1. A class with other virtual functions should have a virtual destructor.

2. A class without other virtual functions should not have a virtual destructor.

3. A class designed to be a base class should have a virtual destructor.

4. You shouldn't inherit from classes that don't have virtual functions.

It's a narrow-minded to say that programmers who inherit from "non-virtual" classes have "misunderstood a key concept of object orientation." Which key concept is that, by the way? Object orientation isn't the be all and end all of C++. There are reasons to use inheritance that have nothing to do with run-time polymorphism. Maybe you just want to reduce redundancy and organize your data types in terms of each other.

Another gripe is that on slide 369, she says:

"When I see bald pointers in C++ it is usually a bad sign."

Naked pointers should usually be avoided for memory management. That's true. But they make great iterators, and they're useful, along with references, for passing objects to functions.

On the other hand, seeing the keywords "new" and "delete" in code is usually a bad sign. Resources (not just memory) should be managed by resource management classes. If you try to do it manually, especially in the presence of exceptions and concurrency, it's very easy to cause an inadvertent resource leak.

Re: Deep C and C++ (2011)

#195

Post by blibble »

pjmlp wrote: post #187
kamaal wrote: post #84

Earlier quoted context omitted.

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…

Small rant, so take it with a grain of salt. Personally I don't care about C, due to its unsafe by default design and my background in safer languages for systems programming. I got my first computer, a Timex 2068, at the age of 10. Spent two years mainly playing games and eventually started looking into programming. When I learned C, at the age of 16, I already knew BASIC (Spectrum, GW, Quick, Turbo), Assembly (Z80,…

turbo pascal is as unsafe as C is, just with more verbose syntax.

it has pointers, pointer arithmetic, manual memory allocation, function pointers, casts, unions, you name it.

I bet you could write could write 30 odd rules for cpp and then compile your "pascal" with cc, e.g.:

#define begin {

#define end }

#define := =

#define ^ *

#define @ &

and so on

Re: Deep C and C++ (2011)

#196

Post by FLUX-YOU »

ryandrake wrote: post #140
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…

I cant even remember how many times I've had to ask co-workers, "So, that's what you think your code will do... what does the standard say?" or, "Why did you use int there when the API spec defines the parameter as taking size_t?" or, "You think that code in your inner loop will compile to one machine instruction. Have you actually looked at the compiler's output?" and the looks/responses that I got. There seem to be…

The field has to accept some knowledge deficits if it's going to pretend to meet business demands. I thought the original post heavily implied that the 'dumber' programmer shouldn't be hired or have a job; are we going to turn away all potential C programmers until they've mastered everything that the 'smarter' programmer knew? I'd say that would heavily discourage new C programmers if they had to commit to mastering all of that before they could think about getting a position. That would lead to shortages, of course.

Re: Deep C and C++ (2011)

#197

Post by pjmlp »

blibble wrote: post #195
pjmlp wrote: post #187

Earlier quoted context omitted.

Small rant, so take it with a grain of salt. Personally I don't care about C, due to its unsafe by default design and my background in safer languages for systems programming. I got my first computer, a Timex 2068, at the age of 10. Spent two years mainly playing games and eventually started looking into programming. When I learned C, at the age of 16, I already knew BASIC (Spectrum, GW, Quick, Turbo), Assembly (Z80,…

turbo pascal is as unsafe as C is, just with more verbose syntax. it has pointers, pointer arithmetic, manual memory allocation, function pointers, casts, unions, you name it. I bet you could write could write 30 odd rules for cpp and then compile your "pascal" with cc, e.g.: #define begin { #define end } #define := = #define ^ * #define @ & and so on

No it is not, because:

- It has real strings

- Arrays don't decay to pointers

- It has reference arguments, which avoid pointer usage for records and out arguments

- Requires explicit casts for type conversions, instead of implicit type casts

- Provides region allocators, which allow to release a full block of memory in one go

- Has real enumerations that don't decay into ints

- Allows writing generic code over arrays without requiring the developer to manage a separate length variable

- Has proper memory allocation constructs instead of requiring the developer to know the size of memory to allocate

Finally, there are other languages in the Pascal family, that provide safety, while allowing for C dirty tricks done explicitly via a system/unsafe package which provides much fine control over the use of said features.

Re: Deep C and C++ (2011)

#198

Post by NAFV_P »

kenko wrote: post #181
NAFV_P wrote: post #159

Earlier quoted context omitted.

"C programming is a craft that takes years to perfect. A reasonably sharp person can learn the basics of C quite quickly. But it takes much longer to master the nuances of the language and to write enough programs, and enough different programs, to become an expert. In natural language terms, this is the difference between being able to order a cup of coffee in Paris, and (on the Metro) being able to tell a native Pa…

"where to get off" has at least three interpretations---the one you note, one in which you insulte the Parisienne (why a Parisienne? Why not the English word, which has the advantage of being gender-neutral, "Parisian"?), and the (presumably) intended interpretation, what exit to use.

"why a Parisienne? Why not the English word, which has the advantage of being gender-neutral, "Parisian"?" I believe I did use the term Parisian.... I could have used the even more offensive (joke) term "parisite".

Re: Deep C and C++ (2011)

#199

Post by qznc »

bloodorange wrote: post #124
pjungwir wrote: post #76

Earlier quoted context omitted.

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

I know at least one guy, who is on it. http://herbsutter.com/gotw/

Re: Deep C and C++ (2011)

#200

Post by NAFV_P »

xradionut wrote: post #176
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.

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 web talk about x86 assembly, yet my processor is 64-bit. I'm quite sure that the principles extend easily from one register size to another, but I have no experience at all in assembly.
Post reply on HN