Originally Posted by johnsfine

I strongly prefer C++ over C, but a beginner needs to work with a well chosen subset of C++.

The strength of C is that a smart person can learn pretty much all of it and then the rest is learning to program well, rather than learning the language well.

In C++, most of the advanced constructs won't make any sense until you are very experienced in the basics of C++. Unless you have an incredibly good memory, you'll never learn C++ the way most good C programmers used to learn C (know all the rules and never need to look up an obscure detail). But for advanced C++ programmers, obscure details are easy to look up in the rare cases you need them. You don't need to memorize all the rules.

C strings are a nightmare for most beginning C programmers. Once you have solid experience with pointers in C and C++, learning C strings could be easy. But a C beginner needs to learn them the other way around. You need to learn C strings early, before you are ready to understand them. In C++, there is a sane and friendly string class that is much easier to learn early.

Much of C I/O (especially scanf) is ugly and is the subset of C that a C++ expert will probably never need, and like C strings, something a C beginner must learn before learning the related concepts that might make it easier. C++ I/O is much more beginner friendly.

The C++ vector class is also a lot easier to work with than C arrays. A really expert C++ programmer must know when it is better to use a C array instead of a C++ vector. But a C++ beginner can learn vector first and worry about C arrays much later.

All the above are reasons that C++, despite being a harder language, may be more beginner friendly than C.

As you build bigger projects, the real advantages of C++ over C become more evident:

Overloading functions (same function name for many different functions distinguished by argument type) is a very good feature. I used to work on big C projects and function naming was a major pain. You can never use the obvious name for a function because that name was already taken by some other function. Overloading is horribly abused in a lot of badly written C++ code. Sometimes you will be tempted to give many functions the same name, but experience would tell you it is better not to. It takes experience and judgement to know when it is clearer to reuse a name for many functions with the same purpose but different inputs, vs. choosing different names for clarity (or for other code maintenance reasons).

Originally Posted by VisionIncision

Also, what are your views on OOP? Some swear by it, others loathe it.

Originally Posted by VisionIncision

What would you say about C++ being used as a procedural alternative to C, i.e. not used for OOP?

Originally Posted by johnsfine

I strongly prefer C++ over C, but a beginner needs to work with a well chosen subset of C++.
...

Originally Posted by johnsfine

I first did OOP in a programming group dominated by OOP fanatics. So I loathed it.

I find the optional OOP in C++ a very powerful tool for a good programmer. But that is a tricky spectrum. I find the extreme of optional OOP in Python to be too big an invitation to write really terrible code. Maybe if I had ever coded a Python project from scratch, I would have found a way to write good code. But just about every project I've ever worked on in any language had a pile of terrible code in it before I arrived. In C or Java or C++, building on a project's rotten foundation is a big but manageable problem. In Python it is hopeless, specifically because of the excess flexibility of optional OOP.

I hate strict encapsulation in OOP. The frequent hassle in working in a C++ project that you never get in C is the data you want to access is in an object that is not easily available from where you want to access it. The constant mantra of OOP fanatics is that a well designed program always fits the OOP paradigm, so when encapsulation or inheritance don't work out, it is because the design is wrong, not the paradigm. An experienced software engineer knows better. Many problems just don't fit strict OOP.

I really like inheritance and polymorphism in OOP. I was writing polymorphic objects in ASM and C long before C++ existed, but having the language do the book keeping leads to more maintainable code.



You could write entirely non OOP code in C++. Use some pre defined classes like std::string and std::vector and the file stuff, but never write any non trivial classes yourself.

I don't see the point.

Once you get used to the odd syntax and understand its meaning, having functions defined in your structs is a powerful feature. It adds a lot of clarity to some of those massive overloads of common function names I mentioned earlier.

Having constructors and destructors called automatically at the right time is another powerful feature, as is the ability to redefine the assignment operator or other basic operators.

OOP is a very useful tool. OOP is only a handicap in the hands of OOP fanatics who want everything to be strictly OOP.

Many of my C++ classes have public data members. That was absolutely forbidden in the first group where I did C++ programming. There are a lot of situations in which the extra layer of an accessor function is very helpful between the data and the places that data is used. Usually you don't know you'll want that extra layer until later in project evolution, by which time it is very hard to add. So fanatics forbid ever accessing anything without the extra layer. An experienced programmer can make a better judgement call whether a given data item might ever need that and leave the extra layer out when it won't ever be needed.

Originally Posted by Sergei Steshenko

And that subset might well be "C" .

Originally Posted by Sergei Steshenko

OOP paradigm, especially the whole 14 figuratively speaking levels of inheritance makes understanding of the whole problem being solved quite difficult

Originally Posted by johnsfine

My discussion of C strings and scanf and arrays was intended to preemptively disagree with the fairly common fallacy that C is the best subset of C++

Originally Posted by johnsfine

Is that 14 a reference to something specific, or just a big number?

Template steering is very messy in C++ (I understand it is better in C++1x, but I can't use that at work, so haven't paid it much attention). Sometimes several extra layers of inheritance are used to get around template steering complications. So I have seen code with inheritance more than 14 layers deep. I think I've even seen some of that without involving templates.

I'm sure having many levels of patch makes a code base frustrating. But having many levels of inheritance usually isn't inconvenient.

Much of what I hate about OOP fanatics and the paradigm derives from the whole "is a" vs. "has a" discussion. OOP fanatics will tell you that X should be a base class of Y in exactly the cases where you might say of the real world concepts represented by those classes: "Y is an X", while X should be a data member of X exactly when you would say "Y has an X". Try applying that rule to real software engineering and you quickly find it is nonsense.

Originally Posted by Sergei Steshenko

I don't remember it be that difficult to understand decades ago (I learned "C" in mid eighties) how strings in "C" work and how they are implemented.

Originally Posted by H_TeXMeX_H

The only thing I will say is if you like OOP, obviously use C++. If you don't like OOP (like me), stick with C.

Originally Posted by johnsfine

I learned C in the mid seventies and I also didn't have any confusion over C strings. I taught C and C++ to my four sons and none of them had any confusion over C strings. Several other people that I taught C to also had no confusion over C strings.

But most beginning C programmers are badly confused over C strings. That was true of my classmates at MIT in the 70's. It was true of my sons' classmates, just a few years ago. It was true of surprisingly many junior, but professional, C programmers my then employer hired in the late 80s. It is solidly demonstrated by the beginning C questions and problems posted here at LQ. Even a few people that I taught C to myself were confused by that.

Originally Posted by johnsfine

That was also a point of view for which I preemptively (above) explained my disagreement.

I think the subset of C++ in which you do zero OOP yourself is a better language than C. When you use std:vector or std:string or C++ IO, there is OOP under the hood, but you don't need to be aware of it, just as in using the C library there is likely some embedded asm under the hood but you didn't need to learn embedded asm to use the library.

I prefer to use some of the OOP features of C++ fairly early, even for a beginner. But if you really don't want to code OOP, there are still a lot of reasons to prefer C++ over C.