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

Why I Chose to Learn C

viget.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Why I Chose to Learn C

#71

Post by pjmlp »

daenz wrote: post #4

C really is fantastic language to learn. When I learned it, I also came from the scripting language world (Python, PHP). Having that as a base, then learning C, lead to revelations about how those scripting languages are created, and how the data structures I took for granted in a scripting language are actually implemented. From what I understand in formal CS courses, you learn from the bottom up, but learning from…

You can learn that with any language that compiles to native code, nothing special about C.

Re: Why I Chose to Learn C

#72

Post by pjmlp »

dkhenry wrote: post #9

C programming is still alive and well is many parts of our profession. The biggest reason why is that even though c++ _can_ do memory management like C most of the time programs implemented in it don't and you can really start to loose a grasp as to what your asking the computer to do when you abstract away where your putting all the stuff your unknowingly asking it to make.

Linux and BSD distributions, embedded systems, on other domains developers have moved on.

Re: Why I Chose to Learn C

#73

Post by duaneb »

rayiner wrote: post #69
duaneb wrote: post #68

Earlier quoted context omitted.

Really? Classes never made source more readable? How on earth is `Vector ` or whatever less readable than rolling a custom struct and functions?

Basic logic error (that it doesn't make things more readable doesn't mean that it's less readable). I just don't see the big readability win going from vector_push_back(my_vec, 53) to my_vec.push_back(53)

Oh, well the dot syntax is just, well, syntactic sugar, and arguing that THAT is the reason anyone (who knows what they are doing) uses C++ is silly. It's because of inheritance and DRY so you write less code.

Re: Why I Chose to Learn C

#74

Post by rayiner »

duaneb wrote: post #73
rayiner wrote: post #69

Earlier quoted context omitted.

Basic logic error (that it doesn't make things more readable doesn't mean that it's less readable). I just don't see the big readability win going from vector_push_back(my_vec, 53) to my_vec.push_back(53)

Oh, well the dot syntax is just, well, syntactic sugar, and arguing that THAT is the reason anyone (who knows what they are doing) uses C++ is silly. It's because of inheritance and DRY so you write less code.

Right, and my point is that I've never seen a situation where inheritance really makes things dramatically clearer versus the alternatives (indeed, the mantra in C++ these days is that you should have "has-a" relationships with composition versus "is-a" relationships with inheritance).

I think inheritance/OOP encourages you to draw module boundaries in the wrong place. It encourages you to spread the logic of an object over several modules of code. If you find yourself using inheritance, you'd better ask yourself: could I instead abstract my base class into a self-contained object that my new object could hold a reference to?

See: http://www.paulgraham.com/noop.html

Re: Why I Chose to Learn C

#75

Post by mpyne »

pjmlp wrote: post #70
dkhenry wrote: post #67

Earlier quoted context omitted.

Or you can do what c++ and rust did which is neither reference counting or GC ( yes I know rust has a GC just stay with me for a little). Its a strong and distinct message about what you plan on doing with the memory your getting. When I run across a int* i don't know what your doing with it just by seeing its type, but if I run across a shared_ptr I know its reference counted and will stick around until I am done wi…

I fail to see how that is not reference counting, even if implemented at library level.

shared_ptr probably does use reference counting, but unique_ptr doesn't.

There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere.

C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the unique_ptr is destructed, it knows to destroy the pointed-to object as well and free the memory, but the object itself is not reference-counted per se, there's only the Boolean sense "alive/dead".

Re: Why I Chose to Learn C

#76

Post by pjmlp »

mpyne wrote: post #75
pjmlp wrote: post #70

Earlier quoted context omitted.

I fail to see how that is not reference counting, even if implemented at library level.

shared_ptr probably does use reference counting, but unique_ptr doesn't. There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere. C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the uni…

That is still reference counting in any CS book about automatic memory management algorithms.

Re: Why I Chose to Learn C

#77

Post by mpyne »

pjmlp wrote: post #76
mpyne wrote: post #75

Earlier quoted context omitted.

shared_ptr probably does use reference counting, but unique_ptr doesn't. There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere. C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the uni…

That is still reference counting in any CS book about automatic memory management algorithms.

Only in the sense that

    MOV EAX, EBP
    XOR EBP, EBP
is "reference counting".

Re: Why I Chose to Learn C

#78

Post by pjmlp »

mpyne wrote: post #77
pjmlp wrote: post #76

Earlier quoted context omitted.

That is still reference counting in any CS book about automatic memory management algorithms.

Only in the sense that MOV EAX, EBP XOR EBP, EBP is "reference counting".

x86 implementation detail....
Post reply on HN