4 ms·

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 metaprogra

by j_baker 17y ago

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-Example-Depth/dp/020170353X 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/ http://svn.python.org/view/python/trunk/

bensummers 17y ago
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++.
- tptacek 17y ago
  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.
bcl 17y ago
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.
- scott_s 17y ago
  One can use C++ as C with stricter type enforcement.
aplusbi 17y ago
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.
tptacek 17y ago
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.
- DanielBMarkham 17y ago
  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.
  - tptacek 17y ago
Estragon 17y ago
Seconding the advice to read the python source code. It's very clear.

by j_baker 17y ago

bensummers 17y ago

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

tptacek 17y ago
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.

bcl 17y ago

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.

scott_s 17y ago
One can use C++ as C with stricter type enforcement.

aplusbi 17y ago

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.

tptacek 17y ago

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.

DanielBMarkham 17y ago
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.
- tptacek 17y ago

Estragon 17y ago

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