Object oriented programming with ANSI-C (1993)

"...or find appropriate libraries."

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.

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 ;)

People love C because it's simple.

Figuring out what some C++ code does can be very complex, depending on what particular features the previous developers decided to use.

C is also the lowest common denominator, making it better for certain development tasks (I'm thinking of mainly lower level shared libraries.)

I also don't get it.

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.

Some people think that C is a better language than C++, and may disagree with you on standard library being a "benefit".

You may try to look at "C++ FQA" at http://yosefk.com/c++fqa/ for an example.

And yet your operating system and over half of your userland is in C. Must be doing something right.

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

There are many platforms that have a C compiler, but not a C++ compiler. Sometimes you just don't have the choice.

Well, C is simpler than C++. That means it's simpler to understand exactly what is happening. It's not that far removed from an assembly language.

And you really can't beat C for FFI. If you have a common library you want to share among many different platforms, C is the way to go.

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

    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.

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?

What solution do you propose?

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.

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.

Perhaps you could forget the buzzword and just learn to code well in your chosen language.

Then try another language -- preferrably one that is quite different from what you started with -- to learn a completely different approach.

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.

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.

Use GObject[1] from GLib.

[1]: https://developer.gnome.org/gobject/stable/

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.

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

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