Hacker News Reader

Comment by markessien | Hacker News Reader

What's the point of using C when most modern programs on modern operating systems are written using frameworks that are a form of objectified C?

All serious development frameworks nowadays for desktop applications are either C++ or Objective C. Most native libraries are one of the two. Even the driver SDKs are mostly build on an object oriented approach.

And learning C++, you will know C. Your opinion is a popular opinion among web developers and people who do not do desktop development, but in the real world, it has a lot more advantages to learn C++ instead of C.

View on HN

C is the lingua franca of computer languages. You can create bindings for almost any language if you have a c library. A lot of system libraries are in fact C, not C++: think of stuff like zlib, curl, openssl, libxml, iconv..

Sure, if you know C++ well, you'll be able to do C, but learning C++ is that much harder than C, that it's often not worth the effort. You'll be able to interface with most libraries once you know C, even if you use any other language as your primary tool. Learning C++ won't give you that much extra.

Learning C++ is not much harder than learning C. The difficulty in both languages lies in pointer manipulation and understanding the system below, it does not lie in using classes or templates. If you are a web developer who wants to interface with libraries then your approach is right, but if you are trying to develop a complete piece of software, then what you are saying is just wrong.

You seem to be locked down by a particular perspective on software development, and this is unfortunate.

The difficulty in both languages lies in pointer manipulation and understanding the system below, it does not lie in using classes or templates.

That's utterly untrue. The low-level details of C++ are mostly the same as C's, unless you want to write a shared library in C++ and thus need to extern the C++ symbols, or need to worry about the details of the object-system implementation like vtables, or need to mess with streams and layer them over some communication medium.

What makes C++ fucking hard is the syntax explosion that feels like cleaning up a New Year's Eve confetti with your bare sweaty hands, the template voodoo, and the design patterns that they have tacked on the language to make it more palatable to Satan.

To make it worse, the language is both broad and deep. You can't learn C++ by reading the standard. You have to dip into the culture of one of the big vendors, or schools of programming, to find out what subset of the language is to your liking. Are you writing Bjarne's C++ or GoF's or Alexandrescu's? or perhaps you would prefer to old HP/STL/Meyer C++ to the new kitchen-sink BOOST C++?

Contrast this to Common Lisp, which is a very broad but relatively shallow language; you can read the first few sections of every chapter of the manual and come off a good Lisper, go back and dig deeper and you only get better. OO, functional and procedural Lisp looks relatively the same. If you don't understand a construct, you look up the documentation of the symbol, see its evaluation model and presto. C++? You don't see what's being implemented because higher-level designs are being kludged and modeled with dickish, brittle and contrived tools -- they have no way out of this, as the language insists on C pseudo-similarity and refuses to adopt any kind of clean macro system; they're running out of syntax and CPP is unforgiving. Understanding C++ code then becomes a matter of psychological profiling of the author and even scholarly exegesis and deconstruction ("What did he intend to say?", etc.) requiring a level of empathy hard to muster when you're, in fact, wishing ill and misfortune on the bastard who forced you to look at this mess.

If I were to extend C by adding python style classes on top of it, I would end up with roughly the same number of keywords. I don't think it's true that C++ has a lot of new concepts in the language itself.

I agree that C++ is very library oriented, and it changes your approach to the language, but this is not a fault of the language itself, this is a side-effect of its very wide popularity.

If you have a pattern used by a library, then that is the fault of the library, but not a fault of the language. The language does not come with any patterns.

Templates in C++ are not good, but they are not widely used in the real world. Most people ignore them, and that's good so.

Templates in C++ are not good, but they are not widely used in the real world.

Depends on where your "real world" is. C++ usages are vendor and library dependent. My C++ code looked different in MFC/COM/ATL than in FLTK and that too was different than Qt. Choosing the right C++ becomes a matter of choosing the right vendor, and if that choice isn't up to you, well, tough luck.

"Templates are not used"? Do you mean that you code C++ without the standard library?

The STL is optional. Templates are widely used in container formats, but in real world programming, for example when people model shopping carts or so, most of the code out there does not use templates. Let's get real here and look at a code repository like codeproject or codeguru - those sites hold diverse examples of real world code - and template usage is minimal.

If I were to extend C by adding python style classes on top of it, I would end up with roughly the same number of keywords.

You can use Objective-C as a datapoint here. That's Smalltalk on top of C. You can use the same sort of trick (delimiting the dynamic sends) to recycle the C keywords in the dynamic context, and end up with a language with just a few more keywords than C.

Learning C++ you will not know C. At least, not in the time it could have taken you to learn C by itself. There are a few core differences, and with C++ you'll spend a lot of time learning things that will distract you from the core language. If you want to learn C and understand it's advantages don't assume you'll pick up what you need by learning C++.

Yes you will. It's better to learn C++ straight up, because the things you learn there will help you become a better modern developer compared to just C. The core differences between C and C++ (apart from the entire object oriented thing) are easy for any competent developer to pick up. Were they difficult for you to understand?

The stylistic differences are wide. Learning to for instance do C style APIs using opaque types, extended macro-fu, broader use of function pointers, etc. are the sorts of non-obvious things that good C developers do that you'll mostly miss working just on C++ code-bases.

I don't think that non-obvious and "good developers" should be joined together in one sentence. It's possible to do a lot of macro magic, it's possible to do a lot of function manipulation, but this is not good development. This is efficient development when you are working with projects or systems that require that sort of thing (maybe large dataset manipulation or embedded systems), but in my opinion, doing those things is bad programming.

The reason is simple: They are difficult to understand. Code is communication, and there are two listeners - and when you are pushing function pointers around using macros, the human is going to have huge problems understanding what you are trying to achieve.

So I don't think exploiting particular features of a language to extreme levels when it is unneccesary makes you a good programmer in that language - I actually think it makes you worse.

It's like writing a book - you have a certain vocabulary at your disposal, and you can say almost anything you want with that vocabulary. There are different levels of obscurity in the words you use you can reach - you gain in expressiveness, but you narrow your audience. When you write a book for molecular biologists, then the particular terms you use should not be the same as when you write a biology textbook.

That's why I think that one can be a good C programmer without going much deeper than the C subset commonly used in C++.

This is part of my general philosophy in programming - clarity, simplicity and structure first, efficiency second. The machines will catch sooner or later, anyways.

It's not that those features aren't exposed in C++, it's that C++ has different (more modern) mechanisms for doing the same thing.

C++ has templates, so you don't need to do as much with macros. C++ has virtual functions and overloaded operators (allowing for functors), so you don't need to do as much with function pointers. Structures can have methods in C++, so the way that you'd set up an opaque type is quite different in C++.

C++ also has about 10000 other features as well though, which is what makes it unwieldy to learn. The patterns mentioned above aren't about efficiency; they're about encapsulation.

Just to give an example -- in C++ if you want to set up a callback, for example with an observer pattern, you'd use a pure virtual function (and then pass in a concrete instance of that class) or a functor. You can't do that in C, so you use a function pointer. You learn to work with function pointers more because they're a necessary part of designing C APIs, whereas they're not in C++.

(Note that it's the language I'm best at, followed by C, so this isn't random C++ hating.)

It's not about knowing the core differences, it's that the actual practice of writing a lot of C makes one familiar with its advantages. It's difficult to appreciate the value of C's small size if you are only coding in C++. Without doing a lot of coding in straight C, it'll be a lot harder to understand and recognize the various tricks and techniques other C programmers use to make the most of the small language.

I'm not saying there are no good reasons to learn C++. Just don't think that you'll really appreciate C until you've actually used it all by itself (with maybe a few C++isms here and there like //comments).

Windows API is pure C. GTK is pure C. And these are quite serious (and not exactly obscure) development frameworks.

The Windows API is an array of functions that can be called the same from C as from C++. Microsoft provides several object oriented wrappers for this API, and it's very rare that any significantly large application is not calling the API over some kind of wrapper.

No, I think it's C. It's written in C and was (at least initially) designed to be called from C code. I think #ifdef __cplusplus followed by extern "C" doesn't make a C API C/C++. Also the fact that there are several Microsoft and third-party wrappers out there doesn't make it any less C, at least in my opinion.

I did not say it's C++. It's C, but it's rare that it's used directly as C.

And, uh ... POSIX. The weapon of choice for UNIX black-belts.

Yes but the C++ based MFC wrappers for Win32 make Windows development much easier.

Have you subclassed any GObjects lately? Or otherwise implemented custom GTK widgets? If so, you might know why GTKmm exists (nevermind that PyGTK, GTK# etc are arguably the intended ways to use GTK.) There is a good reason everyone in the Linux world screamed with glee when Nokia LGPLed Qt, and C++ (even the basic stuff) is a big part of that reason.

No qt is the reason. qt is well designed and thought, contrary to gtk. And it's not because qt was written in C++.

I'll second that. Qt is a beautiful toolkit. It's just enough C++ to be useful, and avoids all the templates and obnoxious flotsam that makes that language such a horror. Signals and slots work great, and other tools (qmake for example) are a pleasure to use.

Reply on news.ycombinator.com