Hacker News Reader

Comment by j_baker | Hacker News Reader

I might get downvoted for this, but I'd recommend going with C++ before you get into C. You don't have to learn all of the crazy stuff like template metaprogramming, but C++ does have some tools to make C-like programming easier. Personally, I'd use C++ just for the string and vector classes.

If you do want to go the C++ route, I hear good things about this book: http://www.amazon.com/Accelerated-Practical-Programming-Exam...

Now that I think about it though, if you're still deadset on using C, the Python source code is actually a pretty easy read. You get two benefits for the price of one: you learn C and you get to learn more about the internals of Python. Look here: http://svn.python.org/view/python/trunk/

View on HN

Strong disagree for a bunch of reasons.

First, there's no style of C++ I've seen in the field that totally eliminates any of the C-isms. Modern C++ code still has pointer math and it still has function pointers. In other words, you still have to learn the trickiest stuff from C.

Second, while <vector> is great, it's not a good idea to think about it as a black box. The whole food chain of STL containers from list to dequeue presumes that you understand the tradeoffs in actually implementing data structures in memory. How do you select and use these things intelligently if you've never even implemented a linked list? You're basically just writing a very verbose and very error prone form of Java.

Finally, C++ just isn't a very good language. There is nothing you can do in C++ that you can't deal with in C. There is a clear difference between the outcomes of, say, Perl and Python --- Python code is clearer and more maintainable. There are clear differences between Java outcomes and Rails outcomes --- the Rails code is tighter, smaller, simpler (though perhaps less featureful). Compare giant C and C++ codebases. What's the C++ win?

C vs. C++ is a can of worms. I know. But I've spent quality time in both languages and I'm an unabashed fan of C. I think the 2010 answer to the problem C++ wants to solve is "C and a high-level language". The future belongs to things like Lua (or Python with a better FFI, or...). C++ is a dead end.

This is a great comment but I have to disagree with your conclusion.

I love both C and C++, although I don't use them currently. And I can't imagine using them in the future.

The issue here: is there a language that is both low-level enough to write hardware drivers yet high-level enough to abstract away anything that I might want? Close-enough to the metal to bit flip with the best of them yet powerful enough to create and organize large hunks of code?

I think the answer is pretty clearly C++. C is a very close second, but the entire reason from evolving from C to C++ was large development situations.

Would I write a new web-app in C++? Heck no. But software development is a lot bigger than the little corner of the world I have my fingers in, and I can easily see where C++ will be around 20 years from now -- and for new development, not just maintenance. Perhaps even 50 years. So no, not a dead end by any means.

I use C pretty regularly and I can see why I'd need to keep doing so. If I have a problem that needs a custom data structure and any degree of performance, C is how I can keep from wrestling with metadata bloat and garbage collection.

The problems I tend to solve with C are tightly scoped. They tend to admit to libraries, where I can get a foo_t from foo_open(), and then pass it to the foo_bar() functions. They're inherently encapsulated and reusable.

There are things from C++ that I tend to want when I'm writing C. Most importantly, I want vector, and I want a lookup table that returns results in sorted order. So, I backported those things from STLPort to C and never looked back.

There are also things C++ offers me that I think are bad medicine. Classes with access control (and thus graphs of "friend" relationships): not a win over ADT-style C libraries. Smart pointers: not a win over pool allocators (also: knowing how to write a dirt simple allocator is one of the single biggest performance wins I've seen in my career, and C++ makes that hard). Templates: not a win over clear, simple code and discrete components.

My experience with C++ is that it creates drag. There are more decision points in C++ than in C. Do I write a class or do I abstract into a template? Do I need a special type or is this just a container of primitive types? Do I decompose into a hierarchy or do I write straight-line code? Do I use a functor or do I use abstract classes? C is a get-things-done language. C++ is a talk-about-getting-things-done language. And then code-about-getting-things-done.

It's OK to downvote me.

You've made some awesome points, and I don't disagree that C++ has gotten to the place where you're juggling a freaking lot of stuff around. In straight C you start at point A and code until you reach point B. In C++ if you're not careful you create a map of the known world in Portuguese and then start defining what the word "is" means.

I think back on my C++ production code -- heavy-duty COM stuff, device drivers, embedded software -- and I'd still stick with C++. The trick is that I wouldn't pull in every feature from all over the place.

Modern languages -- especially those that have been around for a long time -- have a lot of cruft. Do you need templates on every project? Most likely not. Do you need the STL? Maybe bits of it but not all by any means. Do you need a freaking class graph with 50 nodes to start sorting integers? No, but bad programmers will make one.

One of the reasons I love C++ is that it makes you understand how to differentiate the bullshit from the solution. This is the flip-side of the exact point you made about having so many options. Got a problem with allocation? Roll an allocator. C++ is the nuclear bomb of power tools, and there are a million ways to cut your arm off.

But for small utilities where you don't touch the metal or interact with some larger, more complex system? C++ isn't the tool.

I completely agree that C++ has some really bad/ouch-don't-do-that things in there. I just think that overall the pluses outweigh the minuses for a certain small set of problems. (and coders)

You see C++ as a nuclear weapon. I see it as that automatic hammer Homer Simpson made after he visited the Edison museum.

Keeping the topic to "should I learn C++" and "will there be a C++ in the future"

Want to program the iPhone? Learn Objective-C, a bastardized C++ language

Want to build some shit-hot hardware for NASA or the Defense Department? Pick up VxWorks and WindRiver -- and welcome to C++

Want to write your own O/S kernal? Hell if I'd do it in C. C++ gives me nice namespaces and modules and an easier way of organizing things.

So yes, C++ is going to be around for a long, long time. And the concepts you learn in C++ -- assuming you can become a good C++ programmer -- are going to make you a much more proficient programmer in any of the "better" languages.

But fair warning: if you dabble? Yes, you'll be Homer Simpson.

No idea why you got downmodded --- perhaps for the crack about OS kernels, though. Every mainstream OS kernel is C.

Beats me. I didn't say the existing kernels were C++. I said if I wanted to write a new one it would be in C++. I certainly know the existing kernels are C++. Some of the kernel code for popular Operating Systems -- in production now -- goes back 30 or 40 years.

If I'm not mistaken, the Windows kernel has evolved quite a bit to C++. Even the core C files are compiled using the C++ switches. Not sure, but not relevant to my point either.

Hope this discussion helps the poster, which is the goal here. Like I said, you made some great points, and I agree with quite a bit of what you wrote. But understanding the exceptions and edge cases are important, even if the guy doesn't choose C++.

The reason why you probably would want to write your kernel in C over C++ is that C++ does more 'under the hood' and when you're writing an OS you want to have your code as transparent as it can possibly get. Any side effects that are not explicitly mentioned in the code will get you burned at some point.

In what sort of workload was a custom allocator the biggest performance win?

I won't disagree with any of your points. However, we're moving from "how can I learn C?" into "which is better, C or C++?". My point is that C++ gives you room to play around with pointers and whatnot without getting overwhelmed by them. I think a lot depends on learning style. Some people may prefer to dive right into C. Others might prefer to start with C++. Different strokes and all.

I won't downvote, but I will disagree. Anyone programming in C++ needs to know C first. The same goes for ObjC (which in my opinion is superior to C++). Build on a solid foundation before jumping for the shiny looking brass ring of object and garbage collection.

One can use C++ as C with stricter type enforcement.

That's fairly reasonable advice. C++ as a better C, using the STL to avoid having to reinvent data structures is a nicer language.

However, you still want to understand pointers. There's a C++ style which avoids them, but understanding pointers is critical to understanding C and C++.

The problem with this worldview is that if you don't want to reimplement data structures, you might as well stay in a modern language. Control over memory layouts (either for performance or for systems programming) is the reason to be in C/C++ in the first place.

I think it's best to treat C and C++ as separate languages. While you can certain compile (most) C programs with a C++ compiler in practice the way you code in C and the way you code in C++ is very different.

Seconding the advice to read the python source code. It's very clear.

Reply on news.ycombinator.com