When people tell me that they love C, I don't get it.
C is so tiny that if you're going to write anything non-trivial you either have to re-implement various common data-structures yourself, or find appropriate libraries. No built-in string type, no vectors, no nothing. Also, the lack of generics makes for really ugly code, filled with void pointers and casts whenever you attempt to write type agnostic data structures such as lists, queues, etc.
It also seems that whenever I have to write in C, I end up writing code that painfully wants to be object-oriented, or implementing features that are already part of C++.
So why would you willfully pick to use C when C++ is around?
Heck, even if some sick reason you don't want to use explicitly use objects, at least you can enjoy some of the other benefits of C++ (e.g. its standard library).
But... finding appropriate libraries is generally simple. Due to C++'s ongoing ABI issues C is, to this day, still the predominate language for library authors who want their library to be nearly universally consumable (in C, C++, Python, Go, Ruby, node/JavaScript, etc).
That said, I agree with part of your point which is why I use Go when I can today (though it also isn't suitable to be a C-like universal library language for other reasons). Built in strings, interfaces, maps, etc remove a lot of the basic code level pain points without also introducing the overbearing level of language complexity of C++/stl/boost (and I say that as someone who spent nearly 10 years programming professionally in C++ and at one time misguidedly considered myself a fan of the language).
Go is not so big on the full spectrum of traditional object orientation or generics, but once adapting to OO solely by composition and duck-type interfaces I haven't found either of those to be a big issue for me.
It also seems that whenever I have to write in C, I end up writing code that painfully wants to be object-oriented, or implementing features that are already part of C++.
So I guess you just don't really know/aren't comfortable with C. That's fine, but that hardly means that everyone else has the same problem.
So why would you willfully pick to use C when C++ is around?
Because they are two very different languages and have their own strengths and weaknesses?
OO is not the "one true way", that has been shown time and time again. It's really not difficult to find a library for things you need in C. The fact that they aren't all available to include the moment you open your editor/IDE isn't a reason to use C++.
I use both C and C++ regularly. I love a lot of things about C++, but it also brings a lot of baggage along with it. It is an extremely complex language and I have seen some really, terribly awful code written in it.
I've seen bad C code as well, but C++ makes it easier to write bad code and harder to restructure it if you need to because you have to deal with much more abstraction. C++ also lends itself to writing code which contains very subtle errors in it. C makes that more difficult.
I read your post and I just hear someone with little C experience who loves his objects and can't fathom doing things another way.
You can't do generics in very much generality without compromising safety, true. You can get some (sometimes a surprising amount) done with macros, and safer now with static casts. Templates are still a win though, to be sure (syntax aside...)
>C is so tiny that if you're going to write anything non-trivial you ...
pretty much know exactly how you're going to write it from the start. Since C is so constrained it's very easy to design for, and you usually have a very clear idea of what you are getting into, even if that includes reimplementing a common data structure or using external libraries. And if you are using an external library, the API is not likely to surprise you. There are countlessly fewer ways to design something within the rules of the language in C than C++. Different people will see this as a blessing or a curse.
For some situations it just makes sense. If your program revolves heavily around C libraries you will likely be forced into a C-like design anyway. And likewise, if you are designing a library with a primary interface in C. If you are already coding in this style, C offers some niceities to (ab)use that C++ doesn't (especially compound literals, designated initializers, and VLAs).
It's easy to become familiar with C which makes it easy for C to be a go-to language (obviously this depends on your problem space.)
> So why would you willfully pick to use C when C++ is around?
There are many reasons to not use C. But C++ existing is not one of them. Over the 15 years or so that I've used C++, there is always the constant nagging feeling that I don't really know what is going on. My programs tend to work. But I often find that there are incredibly subtle nuances buried deep in the C++ run time model that are simply beyond comprehension.
If you can keep all the rules of C++ in your head, then you are a god among gods.
Today there are few reasons to even need C++. I tend to stick with C or go to Perl/Python. I don't really need a language that attempts to straddle the middle. Especially one that more often than not, gets it all wrong anyway.
Windows kernel code is being made C++ compliant given that C is a legacy language from Microsoft's point of view. Many new APIs since Windows XP are being made available only as COM objects.
As of Windows 8, the DDK officially supports C++ and many of the samples have been updated accordingly.
> OSX kernel is C. Drivers being written in C++ is irrelevant.
A kernel without drivers is useless.
> Windows kernel is C, the fact that they are making it compilable by a C++ compiler is irrelevant.
It is not irrelevant. Code compiled by a C++ compiler is C++, regardless how C fans try to bend it. Having this discussion since 1993.
Besides many new APIs since Windows XP are COM only as well.
C is legacy according to Microsoft, unless they change their mind about it. Even the latest C99 additions to their compiler were done as a requirement for C++11/14 compliance, not because they changed their mind.
> So what's your point exactly? Let us not forget you said that nothing outside *NIX was C, and you are wrong.
L4, Genode, OS/400, BeOS, Symbian are also done in C++.
What other OS, non UNIX based with the same maturity as the list above, can you point out being done in C?
UNIX based systems are the only ones that will be fully done in C due to their symbiotic relationship and the way their developers consider a sacrilege to use something else.
So... I guess I am confused. Here is how this has gone:
You: The only widely used, mature OS which is written in C is *NIX.
Me: No. The Windows and OSX kernels are written in C.
You: Yes, but OSX drivers are C++ and Windows is moving toward being able to be compiled by a C++ compiler.
Me: Right... but they are still written in C.
You: Yes, but that doesn't matter, you're wrong.
Me: ?
The discussion was centered around these kernels being written in C. They are, you have even conceded to that, yet you continue to argue (what point I don't even know) because OSX drivers are in C++ and Windows may some day in the theoretical future be compiled by a C++ compiler? I don't get it.
So you don't get that a kernel without drivers cannot even boot. Drivers that are an integral part of the kernel, thus making an C/C++ hybrid, not pure C.
As for Windows, given the ongoing transition, and some of the chapters of Windows Internals book series, how can you prove that everything is still compiled with the C compiler and not C++ one?
You are right, it is silly to keep this discussion.
When I got to learn C, back in 1992, I was already doing system programming in MS-DOS with Turbo Pascal.
A language with support for OOP, proper modules, blazing compile times, strings, vectors that don't decay into pointers, safer while offering the same low level features as C.
C looked stone age to me, luckily I got into C++ a few months later and saw a language which gave me back most of the features Turbo Pascal had, with the advantage of being a language in the process of being standardized.
I only used C when forced to do so during university assignments and on my first job.
Sadly C's compatibility is what helped C++ to become widespread, but also the cause of many of its issues in terms of security. At least with modern C++ is possible to avoid Cisms as much as possible.
I've found this too. It's rather turned me off using C for anything; in no time at all, I always find myself doing something that would be very straightforward in C++, but is a certain amount of bother in C. So (I ask myself)... what is this buying me again? What's the point?
Fortunately, most C++ compilers' support for inline C code is excellent. Even gcc didn't get it wrong ;)
In what are these various common data-structures supposed to be implemented? Also in a language that already has them?
We have to keep building and maintaining a kernel, a libc, and other basic infrastructure software. Should we also do that in a language that implements the missing things already? Maybe the CPU itself should implement these common data structures?
Relative noob here,
I'm learning programming in general and I picked C to start with. My university courses are pretty shitty so I have to do it by myself.
OOP is pretty repulsive to me. I don't know why. Too many abstraction that I can't see clearly.
Would any of you recommend me to try and get the hang of OOP using C or should I just pick up Java or C++ ?
(sorry if this is a inappropriate comment on this post)
To just get the hang of OOP, you might be better off starting with Python or Ruby (or some other language with a REPL). Although you can do OOP style programming in C (and it's a fun exercise), there's a lot of low level stuff that's really interesting but not particularly relevant to the basic concepts of OOP.
If the choice is between just Java and C++, I'd go with Java, but it probably depends on what your long term goals are.
In any case, learning any language can't hurt, so I don't think there's any danger of making the wrong choice--unless you get so stuck that you're not making any progress. Just pick whatever "fits your brain" then branch out later.
I would suggest Java. It has a really clean object model, is statically typed, and if you use Eclipse it will compile-as-you-write to highlight errors, suggest fixes, and autocomplete a lot of useful stuff like methods you can call on an object.
While you are at it, read "Effective Java" by Josh Bloch--it's full of excellent advice about OOP, and applies way beyond Java itself.
My biggest epiphany about OOP was realizing that just because you can use inheritance, you don't have to use it everywhere. You read a lot of toy examples where you have e.g. a shape, then you have children like square, rectangle, etc. and try to do everything this way in your projects. But it's actually often a really bad idea to overdo it, and Effective Java has some good explanations on the tradeoffs.
Consider a dynamic language to get a grounding on the abstaction. OOPS concepts make more sense in those especially if your doing windowing and graphics. May be worth it to look at smalltalk or ruby.
Unless you're working on ancient software or writing an OO programming language that translates to C, you really shouldn't need to worry about OOP in C. I suggest learning as much as you can about C and then graduate to C++. Java would be fine, too (as would C# or Python or whatever), but I personally like writing C++ whenever I can. It's a nice blend of low-level system programming and high-level abstractions. C++11 is even better with standard threads, clocks, promises, futures, anonymous functions, and so on.
You could try Objective-C. It's proper OOP with messages, and you can write normal C style stuff. None of C++ stupidity (like cout<<"Hello World", yuck).
Perhaps the kinds of applications you've build don't lend themselves particulary well to OOP methodologies. Certainly OOP is very useful in most "business" apps.
I had to make an application framework something like this with ANSI C in the 90s. Make a structure (or two) full of function pointers as an "interface", pass it (them) as the first parameter to all the relevant functions as "this"/"self". (wait, that kinda looks like what "Go" does - hmmmm)
Of course, some in the company tried to pad their resumes with actual (gahd-awwwful) C++. Lovely jewels like this:
if ( output_format == A) {
a.write_pg_header();
} else {
b.write_pg_header();
}
Guess they never heard of a virtual method. Then there's the fun of all the memory leaks from copy constructors and other silly C++ pitfalls.
Simulated OOP in C is an interesting exercise. I suppose if I had not learned an OOP language other than C++ first, I would have thought C++ is just how (hard) it's supposed to be :-)
I did as well in 1988, but mine was missing a lot of things as I didn't have any good examples to base it on. All I had ever read was the Smalltalk issue of Byte.
Also did an OOP emulation a few years earlier than this using Clipper 5, of all things. No structs, but you could make constants for array indices, and assign a closure/block to each array element, using the array as a virtual method table.
I ran into this a while back. Worth knowing about I think. I'd like to see a compare-and-contrast with "Writing Bug-free C Code." (http://www.duckware.com/bugfreec/index.html)
I have read Object oriented programming with ANSI-C and implemented my own class system in C with inheritance and polymorphism.
Taking a look at Writing Bug-free C Code the chapter about class is really just an example how to use structs with pointers that don't expose the underlying implementation.
If you want to learn oop read the Oop with Ansi-C, where classes similar to c++ with certain limitations are possible. The book explains everything in detail with including source code[http://www.cs.rit.edu/~ats/books/ooc-14.01.03.tar.gz].
This seems to be the horrible Schreiner book. IIRC, he tries to do OO in C by using a special pre-processor. Sorry, this approach has never been relevant.
Yes a single chapter is dedicated to that, all the code is beforehand explained and then implemented in the preprocessor. Everything can be implemented by hand. The point of the books seems to be mostly educational, if you would decide to actually use oop in serious projects then writing your own preprocessor would solve two problems. The tedious manual table/pointer writing and avoiding mistakes coming from the former.
I would love to get some book recommendation regarding the subject from you.
"
struct Circle { const struct Point _; int rad; };
We let the derived structure start with a copy of the base structure that we are
extending. Information hiding demands that we should never reach into the base
structure directly; therefore, we use an almost invisible underscore as its name and
we declare it to be constto ward off careless assignments.
"
This looks so manual that reminds me "C with classes". It is a very pedagogic read though.
Big C/C++ fan here, although I'm sure writing software for PC in C is extremely painful. Personally for PC soft I'm using C++ (Qt) but I actually really had to learn some 'higher level' language for this particular job.
However, my main area of interest are microcontrollers and there is NO other option than learning C (C++ compilers costs too much for a hobby projects).
C is so tiny that if you're going to write anything non-trivial you either have to re-implement various common data-structures yourself, or find appropriate libraries. No built-in string type, no vectors, no nothing. Also, the lack of generics makes for really ugly code, filled with void pointers and casts whenever you attempt to write type agnostic data structures such as lists, queues, etc.
It also seems that whenever I have to write in C, I end up writing code that painfully wants to be object-oriented, or implementing features that are already part of C++.
So why would you willfully pick to use C when C++ is around? Heck, even if some sick reason you don't want to use explicitly use objects, at least you can enjoy some of the other benefits of C++ (e.g. its standard library).