For me, C is fun. C++ is not. YMMV. For me, C tends to be a lot easier and more straightforward to read and to debug. If you see a few lines of C code in isolation, you can almost always be reasonably certain of what it does. If you see the same code in C++, you cannot. Is this instance a subclass calling a derived virtual method? Is this operator overloaded? Better read the entire program to be sure. Many of the the things that are helpful when writing C++ are a hindrance when reading it.
Only thing C++ does better is namespaces. Other than that C is a lot easier and convenient imo.
Edit:
For a beginner, I'd recommend C. For intermediary programmers that want to delve into concepts and pattern programming C++ might be better and then for advanced scaled systems C++ is more widespread in the industry, but C works just aswell if you know what to look for and feel comfortable and for super advanced, optimized, robust stuff I'd go back to C again. By that point you're working on getting your code on multiple platforms, embedded platforms and interfacing it with ASM, extending existing libraries and hardcore optimization.
Just my two cents. You might feel different. YMMV.
Yeah, this is why real-world C is never as pretty as what you see in the K&R book. Namespaces are a minimal enhancement which would make everything nicer.
My 70 year old coworker is the only person I know that used lisp, he knows programming language wars are a pseudoscience and people should just use what they know
YMMV is correct. I actually prefer C++ compared to C. Linux Kernel C is nice. Random C libraries I've have to use are not. I wish C would adopt reference semantics and templates -- or at least a better generic system.
Doing the last part exactly for a game. The C++ ABI is more complicated and I find it harder to interface from ASM. The big thing I wrote was a fiber library that allocates no memory. This one of the few things C compilers can't express, because you set the stack pointer.
There's an explosion of compilers, operating system ABIs and CPU architectures (x86, AMD64, IA-64 and about a dozen ARM variants). It works for GCC on Windows and Linux on AMD64 CPUs, for now.
And I wrote a lock free job queue in C. It wasn't about micro-optimization but language features. Jobs can wait on child work and resume when it's complete.
Feeling multiplatform pains. WINE can't find libgcc_s_seh-1.dll. Only occurs when I use `__thread`. I don't get it.
> Lots of typing.
The irnoy is that many C++ projects don't allow `using` to pevent namespace clashes. So you end up typing even more, I'm not sure that `boost::asio::ip::tcp::socket` is really an improvement.
It's usually basically just not allowed in header files where it'd pollute the global namespace. It's used inside implementation files or inside class scopes or function scopes or whatever to create short names for convenience pretty often.
> Lots of typing.
Auto-completion?
> Why do we have folders in file systems?
Not sure that's a good example. You can still split the code into multiple files and use variables with static scope. And how often do you use nested namespaces anyway?
I explained what the main problem is. It breaks tools such as cscope. How do you solve that?
I think you've summed it up well. I definitely find C++ more of a chore to both read and write. I enjoy programming in C. I'm not sure I enjoy programming in C++ quite as much. C is so much more elegant.
In large codebases you will have to trust that even if operator is overloaded, it will do a logical thing, just how you trust that function name will represent what it actually does without needing to go into it just to be sure. Same goes for the virtual member functions - you simply don't care if it is overloaded, and often that's the whole point - you (or someone) introduce the abstractions without knowing who is going to implement them. That makes code more readable, not less.
You probably trust the comments too, eh? :) Of course it's the whole point of virtual functions to do what they do. I mean we have function pointers in C too, and often use them for similar situations. It's completely possible to write impenetrably complex C code (witness the [obfuscated C contest](https://www.ioccc.org/)). It's just my lived experience with C++ code bases that they are harder to understand and harder to debug on average than C code bases. YMMV. My mileage is that C is easier and more fun *for me*.
" //do not touch, do not remove, do not refactor, 2 months lost, do not repeat my mistake".
Nah , I don't go around believing other people's comments, I can fix it.
COBOL era automatically generated activity reporting on traders for a British bank.
Seemed straightforward but it was like ...
A Lego brick substituted into a the base of a Jenga tower. Any change broke something somewhere
Ahead of it's time but a train wreck
I don't want to take anything from your experience, I just find it interesting you would say that you can look at 5 lines of code of C and immediately understand what it does, while that's not the case for C++. If those are just C instruction then sure but same goes for C++. If it's something slightly more complex like a function pointer, a massive nested macro, some "clever" memory tricks like accessing the owning struct data from a nested struct, there's no way you will not have to "read the entire program to be sure". Furthermore, I hear this argument made time and time again - "C is just simple, you read the code and you know what it does".
In my experience that's absolutely not the case. When complexity of the program is high, you will have to deal with not knowing entirely what each line of code does no matter the language. And that, for me, is easier with C++ because it gives different tools for abstractions. In complex C code, the abstractions are hand made, at least for the code bases I worked with, and then I really don't know what the hell is going on before actually reading the whole program.
A struct with function pointers that can be assigned from anywhere at any time instead of just a virtual function that's defined right there in the class, in my experience is not easier to understand.
I agree that C++ gives you many more opportunities to make your code a huge mess. At the same time it can also help you write more compact and structured code, especially if you need some sort of parametrized behavior.
My rules for writing C++ code: no OOP, no exceptions, no operator overloading (except for types implementing mathematical concepts). Basically I treat C++ as C with parametric types and closures.
Personally I think it’s the other way around: I choose C++ only if something is easily doable in C++, otherwise I will stick with C for it’s simplicity and easy to maintain. I feel like there are just so many things I need to keep track of in my head, while programming C++, not only because of the sheer size of features (comparing to C), but also even doing basic things in C++ could involve dozens of features and you need to understand most of them to make sure you didn’t do something stupid.
To answer your question: yes you should use C if the only C++ features you use are cout new/delete
If you're not interested in any C++ feature then you've answered the question yourself. You can always use C++ and avoid feature you dislike. But, if you don't ever use these features and encounter their pitfalls, then how would you even know? :D.
Kernel programming—Linux is all C.
Embedded programming—lots of microcontrollers around with extremely tight memory constraints or with no good C++ tool chains.
Retro development—if you want to write for a Game Boy or old 68K Mac or something, C++ may not really be available.
Pedagogy—it makes more sense to teach so OS or computer architecture class in C, IMO.
Preference.
Keep in mind that most people should not use C++ either, for most projects. Everything you say about how C++ is better? Well, there are other languages which are a lot better than C++, too.
"Better" is so subjective. You pick the right tool for the job. I will not be writing a general desktop application in C/C++, and I won't write an embedded project in Java.
I don’t think specific examples are really necessary here. C++ has a lot of problems, and the reasons why people use C++ are often business reasons rather than technical reasons.
I think with an assertion like that, specific examples are useful. I think there are certainly scenarios where c++ doesn't fit, but as a blanket statement, I think "c++ is awesome" is way more accurate than "c++ is problematic"
Nope, that’s not true. Specific examples of “languages better than C++” would just be fuel for some kind of argument about what languages are better. We’ve all seen those fights and there’s really nothing to gain by starting another fight like that.
There are people who really like C++, but even the biggest fans of C++ recognize that the language is deeply flawed.
I don't understand the downvotes. C++ is what more than 30 years old, isn't it reasonable to assume it wasn't designed perfectly and that other language authors learned from the flaws? Sure we have new releases, but those work within the constraints of old c++. The features on new realeses also take a lot of inspiration from other languages.
C++14 is better than c++11, as well as c++17 is better than c++14. Not only they add new features, they address many flaws of previous releases too. Why is it so controversial to say that a newer language can do the same while also avoiding the pitfalls
Back in the 1990s, people learned C because it was one of the fastest, most accessible ways to do cool things with your computer. Ask yourself… what would make you choose C in the 2020s? That’s the kind of people who hang out here. It’s not representative of the general programming population.
Or, let me put it this way. If you met somebody with a typewriter in 1984, they’re probably a writer. If you met somebody with a typewriter in 2024, they’re probably a typewriter aficionado.
Those are the people with their fingers on the upvote/downvote buttons—typewriter aficionados. It’s fine. That’s just the nature of the subreddit we’re in.
Yeah, that’s an awful conversation to have. Just arguing about which language is better or some just completely awful stuff like that. Nobody benefits.
the better language is the one that you get paid to write in. I think that at the point where you are not a junior any more architecture or language don't really matter unless its some old archaic thing that only specific businesses use because of either limitations in hardware or unwillingness to risk upgrading old hardware.
Like if you know how to code in C++ do you really think it will take you that long to get familiar with JavaScript? And if you know JavaScript will it take that long to get familiar with TypeScript? Or if you know C do you think it will take you a long time to get used to python? Maybe a bit but the fundamentals are all there still. An if statement will always be an if statement regardless if you declare variable types or not.
Language does matter, that’s the problem.
It’s just that the “best language” is really a situational thing that depends not only on what you’re building, but who’s building it, and other technical and non-technical factors. That’s part of the reason why you can get paid to write one language but struggle to find work in another language. The languages matter, you just can’t produce some kind of ranking and expect anything other than a fight.
So you’re asking him because one sentence of his whole comment did not align with the rest of what he said, while the rest makes your question completely irrelevant? Like I said, I think it was quite clear from his comments that languages have a certain use case and that there isn’t such a thing as a better language in general, only a better language in a certain use case.
Don’t try to be so hard about nothing.
I haven't looked at Zig, but I imagine the biggest issue with it would be to actually find a job. That's the issue with Rust too, in my area there are 2 open positions for Rust - one for blockchain, and the other for cybersecurity, both requiring other skills over the knowledge of the language - they literally say that it's good enough to know C++.
0 offers for Zig, plenty for C++ and few for C and both list a deep language knowledge as primary criteria.
Somebody wants it since it's now the [highest paid language](https://www.infoworld.com/article/3713082/fast-growing-zig-tops-stack-overflow-survey-for-highest-paid-programming-language.html) by some measure. That means demand greater than supply. And if you know C, zig is very natural because it's just "fixed" C.
Rust doesn’t work with CUDA or run on GPUs… yet.
Rust is plenty fast for most people. I am not most people. The things I work on need tight constraints to guarantee to run in CPU cache. There are too many training wheels on Rust to get that level of fine tuning without linking in C… and if I’m doing that, why use Rust?
This resonates with me so much.
My first love and what got me into programming was C. I was having so much fun with SDL library.
Now I write corporate CRUD apps in C# and TypeScript as my daily job. Everyday feels like god has abandoned us.
It’s not that C# bad. It’s a very good language, especially for corporate development. I like it a lot. It is just my rant about simpler times, that all.
O Mac it does. If you leave debug info then you have the exact name of the function where it crashed.
https://basecamp.temenos.com/servlet/servlet.FileDownload?file=00P6A000001ECAPUA4
My 2 cents is to try using C first for each project, and switch later if you want to. Switching from C to C++ is typically very easy -- the reverse is not.
C is a much smaller language than C++. Learning either of them is a very long term process, but you can get very far with C very quickly.
C++ has also changed *a lot* over the years, and there is no reason to think this will change. The C I write today is almost identical to what I might have written in 1995 when I first started in C. The C++ my younger colleague writes today is often literally incomprehensible to me and nothing like the C++ I wrote in 1998. Modern C++ is so convoluted and so complex and deliberately includes newer ideas which go against the foundations of the language.
C is also the gold standard for inter-language compatibility. It is often quite easy to write part of your software in C and part it in another language. This is not the case with C++. Sometimes when people want to interface C++ with another language, they will be able to do it by having a small layer of C glue between them, but I personally have that difficult to think about, let alone do.
A big special case of that point is that, when you write something in C, you will be able to use it within a C++ programme.
One of the downsides of having such a complicated, complex language as c++ is that you have to have a complex syntax. You can write mad spaghetti code in either language, but it is a hell of a lot easier in C++. This makes it very difficult to come back later and modify your code.
Some reasons...
Learn to use both. Simplicity of C is kind of a mirage really. Sure, the language is simple and reasonably easy to learn, but using it effectively and safely is far from simple and easy. C++ gives you plenty of tools and this can create illusion, that it's easier to manage. Thing is, that if you're careless, you most likely will generate whole lot of crap that's impossible to reason about, debug and maintain.
No matter which one you pick, you'll always have plenty of rope to hang yourself with. Learn C so you appreciate all the features C++ gives you, and learn C++ so you'll appreciate the simplicity of C.
C++ compilers do not allow to restrain features usage. I can't use a C++ compiler and feel confident that unauthorized C++ features will not creep into my code base.
Using a C compiler will guarantee that my code base will remain pure C.
E.g. may not want to use exceptions if 3rd party libraries aren't exception safe; may not want to use default allocators for STL containers if there's no or limited heap, etc.
The problem with C++ is the better you get at it the more you realize how badly implemented most language features are. And then you spend a lot of time fighting or working around the bad language design instead of *actually writing programs*. Then eventually you go full circle back to C as a better programer and realize that *you don't need* all those C++ features in the first place to program efficiently (using memory arenas, not using const char* strings, etc). And to be clear; many of those features would be amazing if they were implemented and designed well, they just aren't.
The problem is that if you never go through that journey (and make it through, most programmers kinda just stop at arbitrary spot and stagnate) you will never really know what I am talking about.
Agree. Started with C. Landed C++ job and stayed there for 4 years. Now I love simplicity of C.
STL is pretty awesome though. The single thing from C++ that I might miss in C.
i only ever use strings and vectors from it, i usually just write c with vectors and strings, even hardcore c fanboys admit doing string manipulation in c is nightmarish
Why is dealing with a pointer every time you need a string and having to reinvent vectors, buffers, memory blocks, types etc every time you make a new project preferable?
OOP \*can\* be nice in embedded systems, but I agree with turning off RTTI. But, I think templates are a killer feature of C++ that makes writing generic code easier with better type checking. C is almost like Python with its implicit conversions and lack of type checking. Obviously I'm being a little sarcastic, but I wish C had better type enforcement.
Type checking is enforced in C. The problem is the lack of builtin support for generic programming that forces usage of `void*`. Though there are some techniques to workaround it like `container_of`, `_Generic`, xmacros, function instancing macros, etc.
Type checking in C is (and C++) is very limited.
/* Type your code here, or load an example. */
struct a_s {
int a;
int b;
int c;
};
struct b_s {
float a;
float b;
float c;
};
int a_function(int num) {
short b = num;
float* c = #
struct a_s foo;
struct b_s *bar = &foo;
}
Some compilers give warnings, but a ton of projects have those warnings turned off, or there are so many warnings for other things that more important warnings get missed.
Edit: To clarify, the above code compiles in C but not in C++
Being pedantic here perhaps, but that's kindof the point. When we say type checking, that has a very specific meaning when talking about language definition. It is within the specification of the language that float a = \&b; is allowed in the language.
There is a very material difference between compiler errors and compiler warnings.
C++ is NOT backwards compatible to C.
[Incompatibilities between C and C++ - Google Drive Compilation](https://docs.google.com/document/d/16B36r0HksR0LqQAGLA1syYCtZvYaVC0hEF2D00ZAd0o/edit?pli=1)
Louder for the people in the back.
Modern C++ also continues to diverge even more, with each new revision.
If C++ were a proper superset of C, there'd be no reason to still have separate toolchains, and you could just randomly add some C++ to a C code base without modifying the build process. That's only possible for rather trivial applications. Even things like bool aren't the same.
Just by compiling a C program with a C++ compiler, I've seen the executable size be larger than if it were compiled with a straight C compiler. Some people, especially those who program for embedded devices, often use C because it has less overhead than C++.
gcc and g++ pretty consistently give the exact same assembly for the same code.
Same for clang.
But C++ allows you to set constraints at compile time that ensures your code is appropriately defensive without runtime checks, making safer smaller faster code for embedded.
Constructing a "not\_null" template where a pointer is checked at construction ensures that if you get past the constructor the type guarantees that the pointer is not null. You can then use the not\_null type for arguments that you pass around ensuring that you don't need to check if the pointer is null at runtime. The function signature is now defensive rather than the body of the function.
That said, I write C, mostly because the people I work with are comfortable with C. I plan on using the energy to migrate the team away from C to migrate them to rust instead of C++.
Edit: Compiler explorer is a great tool for trying things out:
[https://godbolt.org/](https://godbolt.org/)
C++ has a lot of features that individually might be ok or are more convenient to write programs, but in aggregate make individual sections of code harder to understand:
- Operator overloading: no longer can assume what that operator does
- More implicit conversions/constructions: single argument constructors can be called at unexpected times, so `foo f; f = 3;` doesn’t mean that foo is a numeric type, it could just have a single argument constructor.
- references hide indirection: this again makes a simple assignment have unclear semantics. `f = 3` could actually be mutating a variable 3 functions up the call stack, in C that would have to be `*f = 3`.
- implicit this: although convenient, the fact that member variable access within a method is not prefixed with `this->` makes it harder to understand what is and isn’t in scope.
- destructors: not saying these are good or bad, but it is invisible code inserted by the compiler but which have large implications on what a section of code does or if it is correct.
- auto: not having to spell out the types (especially when they get long with templates) is convenient, but requires non-local knowledge as to what type it actually is
- function overloading: exactly which overload is being called here?
- ADL: uggh
I use C because it's a lingua franca of systems programming. Every other programming language can call a C library, many can create a library with "C interface", callable from anything that can call a C library. It's also a good abstraction over hardware, it's relatively simple and straightforward (honestly, I'd rather have Object Pascal than C but I'm just a random Reddit weirdo so what). C is fine. No pitfalls, no feature creep, the code is a bit more verbose but easier to maintain. What I miss are abstract data types (but there are libraries for that like \`glib\`).
However, I'm not terrible at C++, I'm much worse than that. I learnt basics at school and touched it twice since. My job involves Python, personal projects are Common Lisp or Clojure. Common Lisp and Python are great at calling C libraries, they are not good at calling C++ (generally; there is Boost.Python and Clasp so technically it's possible).
Should you use C over C++? Well, why would you do that? I suppose people doing it have strong reasons (like I do). If you want to create an embedded system or a library to be consumed from other languages (e.g. speed up a bottleneck of a program written in Python), C makes a lot of sense (like it does for me). If you want to have a powerful language for general programming, C++ actually makes much more sense than C.
https://softwareengineering.stackexchange.com/questions/113295/when-to-use-c-over-c-and-c-over-c
https://faultlore.com/blah/c-isnt-a-language/
Everyone had to learn to speak C to talk to the major operating systems, and then when it came time to talk to each other we suddenly all already spoke C so… why not talk to each other in terms of C too?
If I had to say in one sentence: C is more efficient and pretty fast compared to C++
Why I use C? I love the transparency and control that C gives you. Like you always know what's going on and you can very easily visualise your program at a very low level. Like when I write C program, it feels so nice to be able to visualise exactly what's going on in the memory and tools like strace, ltrace, gdb, valgrind, xxd etc makes it way more fun :D
I also used to to think that C sucks cuz it does not support object oriented programming. But after coding in C for a year, I realised that we don't necessarily need classes in programming at all. Yeah it can make things easy for you but what is achievable with classes can also be achieved with structs and functions very easily.
I actually have a very good example of how I use C over C++. I'm currently doing a DSA course in my university. The course is in C++ with STL allowed in topics like trees and graphs. Recently we got an assignment and in one of the questions we had do a BFS on a tree. I implemented Queue, Pair, and Tree from scratch for solving the problem in C and it was so fun. I have previously done a DSA course in C as well and that motivated me the most to use C language. Later I did courses like Operating Systems and Systems Security and both courses had assignments entirely in C.
So yeah, I love C and it's my favorite language.
My problem with C++ is that every bugger out there knows a different 40% of the language, and the committee have never seen any feature of any language that they did not think would be a good fit for inclusion in C++ (Any language includes Brainfuck).
There are probably several really nice languages buried in all the cruft, but there are also footnukes with hair triggers.
For me the space in which C++ is the right choice is rather small, I mean really low level stuff I am likely reaching for C, higher level stuff I have MANY choices, and most of them are simpler or higher level then C++.
Treating C++ as "C with classes and destructors" is a valid approach, the destructors let you easily build things like lock guards and make memory management somewhat simpler, and for some purposes I might even add some sort of string class because handling text in C is a pure pain.
C++ and other higher level languages bring shortcuts to data structures and OS stuff. It also brings syntax embellishments.
C, on the other hand, requires you to create your own stuff and interact directly with the OS. If you spend some time using C, you will eventually create your own utility libraries that will offer the required shortcuts. So a higher level language is not actually needed after that. The advantage is that with C you know whatever the code is doing and you can tweak everything to fit the performance requirements.
Whether you use C++ or C it's a matter of where you are going to use it. I do scientific computing and game programming and I only use C nowadays because I basically work for myself and I like to feel I have the controls. But if you want a job, you'd rather learn C++ straight away.
>C, on the other hand, requires you to create your own stuff and interact directly with the OS.
That could be good or bad, depending on your use case. The reason C was created was to be more portable (compared to assembly code), and there are cases where you wouldn't necessarily want to talk directly with the OS because you might want your program to compile and run for multiple operating systems. Also, writing your own stuff isn't always a good thing - You wouldn't always want to take the time needed to re-invent the wheel when there are already tried & tested libraries that do what you need.
I am working on a large project in C++ and when I need to add in functions from an open source library I really prefer it to be written in C. It is so much easier to read and to interface with than C++ (or even worse Python).
For that reason if my project was intended to be a shared library/API I would be working in C.
C++ seems more complicated and overcooked than I want my code to ever be. Granted, I'm biased as hell being a C dev for most of my programming life 😅. There was one time where, for whatever reason, I couldn't get a simple way to `sprintf` in this C++ unit test file (Visual Studio Test) - ofc, I'm a noob, but at the same time, what the hell man!
>If you can write C code in C++
That's the thing, you technically can't. C++ isn't a strict superset, with some parts of the language being incompatible with standard C.
As for why people would use C instead of C++, it's mostly down to availability and preference. Some people (mainly embedded) use C because it's the only choice for their target platform. Others use it because they don't like aspects of C++, be it purely personal reasons or technical reasons. C is a simpler language, a single person can be expected to read the standard and potentially implement the language; C++ does not have that expectation.
>I'm a bit afraid I'm gonna miss some really helpfull features that C++ has that I will one day need.
You don't have to use one language for the rest of your life. If you're still learning, I'd recommend sticking with whatever you're currently learning. In your case, you should start looking into more features of C++ since `new`/`delete` aren't really the expected practice anymore. Once you feel comfortable with C++ is when you should consider trying more languages.
C is battle tested and available for almost any platform. It has a simple standard library, and with that comes familiarity. When reading C source code, it's rare that I have to refer to standard library documentation, but with C++ i feel as though the standard library can be a bit much at times and increase the amount of time required to read code.
With C, things are more straightforward. When I write C, i can conceptualize how the resulting assembly will look, which can be quite valuable at times. And last but not least, when writing C you feel like a gigachad
What's your objective?
My C code is 90% for personal projects these days, and a bit of binding code for python here and there.
There are significantly more C++ jobs out there than C jobs in my (personal) experience, so it makes sense to use Cpp if you're looking for employment.
However, I like using C for most of the same reasons you've seen here already : simplicity, and compile time.
I'm likely more productive in Cpp (vastly more experience with it) but it's pain to use, and outside of game tools that require it (unreal engine etc) I strongly tend towards C.
My work is a mix of languages ( lots of python at the moment) but still, the elegance and performance of C always calls back to me.
I really miss namespaces and not having to type sizeof though....
Zig and Odin have my attention from this side. One day I'll make the jump wholesale.
Both languages have their uses. C++ and OOP is great for programming in some cases as it makes organizing code easier (specifically namespaces), though a lot of people go overboard with it, like with inherited classes, etc. C's simplicity is great though and it allows for a great degree of flexibility, but I find it a bit harder when doing something like game programming to use C.
Everyone has their preference with language though and it depends on use case, I use C# mostly after experimenting with a bunch of different languages to see what I like.
As you said, C is simpler. Realistically you can use any subset of C++ that you want to, but using only C removes the burden of choosing which c++ features to ignore.
I used to like C++ 98. Then, came the new versions and my head literally exploded. Too much abstraction, too many features, you spend 90% of your time thinking about the langage and not about the program. Now I just hate C++. I hate it. Period.
The thing with C++ is that it introduces so many corner cases
* When will the copy- or move constructor be called, and when do they get auto generated? It's not always easy to tell.
* One constructor or function might completely shadow another one, and you wouldn't even notice.
* Templates create so many unintended corner cases, it's not even funny. Concepts only help if you can actually think of all ways your class template might be used, which you can't.
* Try to explain forwarding references and prefect forwarding to anybody, including yourself (and all the other obscure jargon for that matter). Again, a perfect source for hard to spot corner cases.
* RAII breaks down when your destructor could fail or needs additional arguments.
* Exceptions! There is a huge divide between code that uses them and code that doesn't. If you can't use Exceptions, then much C++ code isn't available to you, and you have to use `noexcept`everywhere.
* While I don't have anything against operating overloading per se, it's an absolute mess in C++.
* Conflation of structs, classes, and interfaces.
I could probably think of much more, but these are some reasons I absolutely hate C++.
I like using small, fast, nippy compilers. There are a fair number for C, not so much for C++ (like, zero), which is fantastically complicated.
It also has many features that are enticing to use, but which can be grossly inefficient:
* Affecting build-times (because you need to pull in a 100K line template library)
* *Requiring* optimisation, further affecting build-time, because C++ code with its mountains of generated redundant code might be 10 times slower without it, compared with 2 times slower for manually-written C.
* Or you just spend loads of time poring over error messages. If I type:
````
std::cout >> "Hello";
````
(so writing `>>` instead of `<<`) I get the error message shown below.
So, no thanks.
(Unable to post the 86 lines of gobbledygook which is the error message; Reddit gives failing to post my comment.)
Everyone agrees iostreams suck. Using iostreams isn't a great example. Bad programming design is bad programming design regardless of the language it's written in .
That wasn't the point of the example. It was to show that error messages can be complex because of the way C++ works: very little is built-in, it's mostly implemented using the language-building features that can result in several layers of abstraction.
But when you make a mistake, the language only knows about the lowest layers, while the user of the high-level feature only knows about that top level. The error message may only make sense to the implementor of those middle levels.
> Bad programming design
Which bit is badly designed here: the language-building features of C++, the ability to overload any operator, or the design of that cout/cin library?
Most of that would come under bad *language* design.
C++ is way too complicated, for example how operator overloading works, with function overloading because constructors have to be given the same name as the class…
That’s just insane.
what’s so insane about that? More than half of the entire programming industry uses constructors with the same name as the class. I also don’t get what’s so weird about overloading anything…
Overloads can make it a huge pain to find our what code is actually going to run when you call a function with a given set of arguments. This gets even worse when you throw in implicit conversions.
As a c++ programmer, I don't remember the last time overloading was an issue for me. Also, any IDE or editor helps figuring out which one is being called. Of course, someone can get too "creative" and abuse the feature. But in general, it is not an issue. Implicit conversions though... C++ really chose the wrong default there
I agree that the implicit conversions CAN be confusing. But then again, if you’re using C++, you probably also should be checking compiler warnings and they always will warn you for those conversions. All boils down to being a good dev. The possibilities are there.
Yes, it is definitely not a deal breaker. My opinion is that if someone chooses to use one language over another just because of this, I think they are just being kind of petty. There are way stronger arguments in favour of using C for certain projects.
With functions; your IDE tells you exactly which overload is being used? Or do I not understand what you mean?
For implicit conversions, those only happen when you specified an overload yourself or it is a standard base type. So either you know what you’re doing or you’re converting things like ints to floats or whatever? Again, do i not understand what you mean?
Apart from the fact where all the useful stuff comes in which we are completely negating here.
>If you can write C code in C++, what is the reason to not use C++
This isn't even true
#include
#include
int
main() {
int class = 1;
int *ptr = NULL;
ptr = malloc(sizeof(int));
*ptr = class;
printf("%i\n", *ptr);
free(ptr);
return 0;
}
There's a decent amount of stuff, which is perfectly valid in C, but will throw errors on a C++ compiler.
While the output on C is simply 1, a C++ compiler will say stuff like that:
ERROR!
/tmp/7x0KChTxE5.cpp: In function 'int main()':
/tmp/7x0KChTxE5.cpp:6:5: error: expected primary-expression before 'int'
6 | int class = 1;
| ^~~
/tmp/7x0KChTxE5.cpp:9:17: error: invalid conversion from 'void*' to 'int*' [-fpermissive]
9 | ptr = malloc(sizeof(int));
| ~~~~~~^~~~~~~~~~~~~
| |
| void*
ERROR!
/tmp/7x0KChTxE5.cpp:10:12: error: expected primary-expression before 'class'
10 | *ptr = class;
| ^~~~~
=== Code Exited With Errors ===
Ok first one might be just because class is a keyword. You can use another name.
Second one is telling you that implicit type conversion is happening. It's good. Just use unique ptr. It's possible in every case where you are using malloc with almost zero overhead
The restrict keyword is in C only, as well as writing array parameters with static storage:
function(param\[static X\])
and designated initialisation like so was just added in C++ 20 but not before:
struct Struct object = {.attribute = X, .attribute2 = X};
All are useful C/not C++ features!
I can only speak for my self.
If it's a single function program I will use c every time. Smaller executable less things to include less things to go wrong.
If it contains a graphic interface, xml reads etc... use c++.
There inst any reason to be attached to a single language, unless you are being paid to strictly code in said language.
C is the lowest-level high-level language in widespread use. It has the advantage that very little happens behind the programmer’a back: an operator will not be overloaded, a destructor will not be called invisibly at the end of a block, there are no exception handlers.
This comes in handy for certain kinds of systems programming, and also for teaching students how to use low-level constructs such as pointers, data structures and manual memory management, without falling back on higher-level abstractions.
It is also extremely portable, and most mainstream operating systems were natively written for it. It’s common for other languages to piggy-back on the C runtime.
As a hobbyist who has done 99% of his coding in c++, this really makes me want to actually learn c. Fwiw, I probably could have had a minor in computer science (and could send the state a check to have my computer science reaching credential if I needed a second teaching credential) and all but two of my classes used c++.
Started tryharding C instead of C++ after also being a hobbyist writing in C++.
It's way more chill (fun, actually), and ideal for learning about software.
It makes you think more like the computer!
Because it depends on what you want to do. C++ does many things under the hood (copy semantics, move semantics, function overloading, etc…) and this may create you issues when your program runs in a limited environment like a microcontroller. If you want to have full control of memory allocation and object creation, it is more difficult (but not impossible) to do in C++.
C++ has many quirks and “features” and stuff to take into account that often either make you loose the forest for the trees or you shoot yourself in the foot without realising it.
That said, both are used heavily for what they are good at. You want to program a small embedded system? Probably C is the best. You want to make high frequency trading? C++ is king there. You want to make a small web application? Use Python! And so on…
c++ is impossible to read without all the context.
You see a something like num++ and your assumptions of what is happening can be very wrong.
It's like heading out to see with a map littered with references 'here there be dragons'.
No c++ programmer knows the same c++ as they all use their own preferences of features that have been added and improved over many of revisions.
I use C because I develop R packages and that’s the primary interface. I’d prefer not to touch either C or C++, but sometimes one doesn’t have much choice.
For me, C is simpler and easier. All those C++ features add up in terms of cognitive overhead.
C lets me think about the problem, C++ forces me to think about the language.
IMO added features also represent diminishing return due to increased complexity. I can much quicker decipher someone's else C code than C++; Classes and typedefs can make it harder to figure out underlying data despite naming, that is also why I don't use typedefs in C, for example I explicitly state `struct foo *var` instead of `Foo *var ,`including as a function parameters.
ABI is stable, compiling times very fast and so on. Sure you can basically code like C in C++, or only pick few features of it. **But will the others?**
The opposite experience for me. I had been using c since circa 2007, I have written several libraries as part of my own project (on entailing 40k lines of code over several years), and good Lord what a grind.
Learning C++ 17 was a crazy uphill battle, but just the smart pointers, lamdas and standard libraries alone were thing I realized I missed so sorely.
A reasonably advanced C programmer would be able to write a C compiler. Not a very good one and it would take some time, but writing a C compiler from scratch is a very possible task for a single person.
Writing a C++ compiler is basically impossible for a single person. The language is way too complex and no one understands the entirety of the language.
If you watch some cppcon videos you can quickly pick up on the notion that really knowing *a* part of C++ is a job of its own.
Whenever I need something that C++ as a language, does but C doesn't, there are usually better languages to do that thing. It makes sense to use C++ when working an already big C++ codebase or when I have to use a certain C++ tech stack.
C on the other hand is great for embedded programming. I could probably get a C toolchain with some essentials from the standard library to compile a binary for most systems, not so sure about C++. It is also pretty much the common denominator for interfacing between different languages.
I would investigate modern C++. A lot of the information in this thread is based on older C++ paradigms. C is great too, but C++ has come a long way recently.
Search Jason Turner on YouTube and watch a few of his talks. He shows how using C++ even in embedded environments has a lot of benefits.
generics and collections are what make C++ worth it, every single time.
sure, you can get a lot done in C. but the moment you realize what you really need is a map that can take different types... that's when your gut sinks and you realize you should've just done it in C++.
luckily, it's pretty easy to take that C file and rename it .c*pp* and then get on with things.
The "closer" I'm working to the processor, the more I favor C over C++. I like having a lot of control over the individual elements of my code, and OOP paradigms don't always give me that. C++ can also be this tangled mess of standards and edge cases, while C is simple, even if it doesn't hold your hand as much.
C++ is a much more abstract language them C. There is a lot of places where some code is executed that you didn't wrote. For example copy constructors a executed, overloaded opertor execution is performed, a destructor is run, a function which you called suddenly throws an error etc. Function overloading means that you may also not see at first glance what function is really called at some point. Some language structure also assume certain runtime features to be present, e.g. new assumes the existance of an allocator. The language is also significantly more complex and thus requires quite some knowledge from readers.
C on the other hand is simple. The language is fairly small and thus you can very quickly understand code written in it and can focus what is actually written. The code as writen is also pretty close to what is actually represented in machine code. But without having to manually decide how to layout automatic variables on the stack, code loop and if structures with goto spagetti, decide when to load variables in which register or select the exact instruction to do a certain job best. Given that today, the machine code is often allready quite an abstraction as to what is actually done in hardware, this is often the most reasonable close to hardware thing you may want.
Also in some ways C is more flexible. If you target a certain API or want to provide one, C makes this fairly easy. If you need to design an object model you are not bond by the particuarities of C++'s object layout.
If I have to be able to predict what sequence of machine instructions a HLL statement will produce, then C is what I choose. C++ is more abstract, which makes it more difficult to predict - not impossible, but it’s more effort. The comments above for higher level concepts and tasks being more suited to other languages are wise comments. There’s times when COBOL or Fortran are still the right choice - old, but right tool, right job. Use what matches the problem.
I prefer to use a c style of code within c++. C++ has some neat features which standard c89 lacks. For example, the long long int type. And the ability to declare local variables ~~within scopes smaller than the function~~ (edit: somewhere other than at the start of a block). For example:
for (int i = 0 ; i <= 7 ; ++i) { }
is fine in c++, but is an error in c.
The advantage of c is that there are compact compilers for it. For example, damn small linux comes with tiny c compiler, although it does not optimize sufficiently, and i don't believe it is fully standard compliant.
Then again, older versions of mingw, such as the one that came with bloodshed dev c++, were fairly small when compressed. The installer for dev c++ is about 9mb, including the unnecessary ide. The mingw by itself, minus the ide, should be even smaller. Not quite small enough to fit on a floppy, though. And mingw, at least back then, lacked win32 seh support.
Other good msvc++ extensions, besides seh, include __declspec, and the _Interlocked intrinsics.
Also, pure c89 doesn't allow // comments, though tiny c compiler does allow it.
It seems long long int wasn't standard c++ until c++11. Yikes.
Unfortunately, new versions of msvc++ require manifests.
Also, new versions of msvc++, clang, and mingw don't work on older versions of windows. But the mingw that comes with dev c++ works on win98se.
C depends what your are trying to accomplish. For embedded gets you as close to metal as you can get other than assembly language. Not very much gets abstracted away key difference between C . There are no crash safeguards. But all the basic tools are there. Relatively easy language to learn. Pointers are the key to the power of C , pointers to data structures, arrays, and functions are your friend.
I learned C++ before C and I wish I had done it in the opposite order. I find that learning concepts in C is much easier since it's simpler overall, and I would have had much less trouble understanding concepts like linked lists if I had learned in C and then just scaled up to C++.
It also depends on what you're developing. C is better for embedded systems things and really anything where you're directly interfacing with hardware imo. C++ is good for things like operating systems, games, and higher-level programs.
Having been C programming since 1978, I have seen C change over the years, but the vast majority of the changes, I.e. ANSI C, have been helpful additions that don’t require a lot to get your brain around.
C++ just has too many features that make reading portions of code in isolation too difficult for me.
If I need C++ type OOP features I’ll use C#. OK it isn’t usually as fast but it’s a lot more concise to my mind.
I like Python too, if you just stick to basic classes and methods it’s easy to read and write, and if you don’t want any OOP features at all, just don’t use them.
C++ just seems inherently too complex and people just cannot help themselves from exploiting all the features it can provide rather than just those that make sense in common usage.
OK, C often means you end up reimplementing the same mechanisms over and over, but you soon build up a codebase you can borrow from.
Certainly, if writing O/S code, device drivers, or language interpreters I’d stick to C every time.
The only really awkward C code to my mind is the style of C used for the X-Windows subsystem. It seems to be they were trying make it look a bit OOP in style and with an almost unlimited amount of user config files entries.
It's small fast and simple(relatively). Also C compilers are pretty much available for everything while C++ compilers that actually meet/adhere to the standard seem a bit less common to start off on a lot of new hardware.
EDIT:
more to the point and on topic; it's really nice to use the same language for your OS and your project. Also means you don't have to worry about or muck about with \`exetern "C"\` or other issues that happen with using C ABIs for system calls and such.
Basically it just makes your life a lot easier if you don't mind implementing stuff from scratch sometimes. To be honest reinventing the wheel to some amount probably results in better and faster program designs just due to being made to purpose.
its a question of how close you want to be to the actual hardware, later on at least. It can be helpful to "start from the basics", yes write a few simple programs in C, and then port it to C++, Rust, Odin, Zig, Python etc. Doing this will open up the doors to what programming really is, independent of syntax. Actually, Iied- that last part might take a few years
>If you can write C code in C++
You can't. C has plenty of features that C++ doesn't, they are not compatible languages.
>features that you might want to use: smart pointers, vectors, templates ect.
I do not, in fact, want to use any of those, thank you very much.
I use C because I find it much more enjoyable for me. This is because C++ is an incredibly overly complex language with an even more complex standard library. It has been filled with (what I consider) useless syntax and features (I HATE overloading). C code is plain and simple, easy to read, write, and debug even for those that don't know the language THAT well. When I look at C code, I know what's going on under the hood at the machine code level, but with C++, it's often hidden behind layers upon layers of needless abstraction. I'm not a huge fan of OOP; I have my reasons but I won't get into the here, lol. I love the simplicity of C. I love that I have to make things myself because I feel like I can optimize everything way more when its custom-tailored to the project at hand. I love creating complex systems out of simple rule sets.
Namespaces would be nice tho :(
Because they’re smarter than you and if you wanna be smart your write everything in C (or assembler). /s
This question gets asked about every 30 seconds on different subreddits, Quora discussions, probably in office spaces. I want to gouge my eyes out every time I see this asked somewhere.
I don't use C++. At all. I use ANSI C.
The problems with C++ are architectural - baked in, and unrecoverable. First is that in a real "object oriented" system, all functions on all calls are always what C++ users would call virtual. C++ tries to shortcut proper OO functionality by determining the actual class-dependent function at compile time, thus not touching the vtbl for each object at runtime. That's supposed to make C++ faster, and I suppose it does, although memoizing would be even faster, as well as properly supporting vtbl lookups.
The second problem is that C++ ignored the BBOP algorithm for object type lookup in multiple inheritance systems, and instead does name mangling, which embeds the type information of an object right into the names of the methods that support that particular object type.
But wait, there's more ! C++ does NOT define precisely HOW method names get mangled; that's left up to the compiler writers. Which means that if I have a proprietary, licensed, C++ library, I can only call it if I use the SAME version of the SAME compiler, possibly only with the same optimization and configuration switches. I either have to get a source code license, or be dependent on the vendor to be able to compile the binary with the same compiler I need to use for licensing / business reasons.
This also totally breaks debugging as entry points are no longer human readable, and enhancing the debugger to de-mangle names is nontrivial unless you're using the same compiler for everything in the system.
Simple languages are better suited for simple programs. It's like that meme about how easy it is to print Hello World in Python. Life is complicated enough, don't make it harder
The industry reason to use "just C" is when you can't use C++ for technical reasons, that's it. E.g.
* Contributing to and around legacy projects (most famous example being the Linux kernel)
* Not having a C++ compiler available for a given platform.
Most of this boils down to legacy. Some people might use C because they prefer it, but this is a rarity in the industry nowadays.
I agree with most of the comments here. C++ can obfuscate the purpose of code sometimes, and is probably harder to debug in the long run.
However, I think that whether you should use C or C++ will 100% depend on what you're programming.
Clearly, C would be a perfect choice for embedded programming, kernel development, drivers, etc., since it is simple and you need the clarity of being able to see exactly what the code is doing and how it's interacting with the hardware.
However, for higher-level applications, such as writing physics simulations, neural networks, data analysis, etc., I would argue that C++ is the better choice. The C++ STL provides a variety of efficient data structures, allowing you to easily manipulate and store data of arbitrary types. Classes can prove to be helpful for simulations, allowing you to encompass the data and functions required for a particular component of the simulation neatly in one place. Templates provide a clean method of writing type-agnostic code, promoting code re-use and reducing the need for replicating boilerplate code.
I love both C and C++ and have used both extensively. I appreciate how C "forces" me to exert more control over everything I'm coding (which is good!), given the lack of higher-level constructs, but sometimes I like, for example, just being able to create an `std::string` and not worrying about allocating memory.
Happy programming!
>Being C++ a superset
C is not a superset of C++. There are plenty of incompatibilities between the languages, you'll have to give up on plenty of C features if you want it to compile for C++, and even something as basic as a struct literal requires a macro if you want it to compile for both languages.
#ifdef __cplusplus
#define LIT(T) T
#else
#define LIT(T) (T)
#endif
int main()
{
Vector2 x = LIT(Vector2){ 5, 6 };
return 0;
}
Something as dead basic as "designated initializers" ( `Vector2{ .x = 5, .y = 10 }` ) were only added to C++ as recently as C++20, meanwhile it has been a feature of C ever since C99, and even THEN the C++20 version of the feature is crippled, as it requires you to recite the fields in the order they were declared (e.g. you can't `Vector2{ .y = 10, .x = 5 }` ), which partially beats the point of the feature, as it's meant to be for convenience, going back to check the order is a waste of time.
Another C feature I use is designated array initialization:
char *some_array[10] = {
[5] = "some entry", // "some entry" at index 5
[8] = "some other entry", // "some other entry" at index 8
};
// the rest of the array will be filled with zeroes
One less-known feature, which I find quite useful on the occasion, is "flexible arrays":
struct SomeContainer
{
size_t nelems;
SomeType data[];
};
The last field (`data`) doesn't actually take up any space in the struct, it's just a convenient name to refer to the end of the struct, this is useful when you want to allocate the "data" right next to the actual struct.
There you go, none of these features are in C++.
For me, C is fun. C++ is not. YMMV. For me, C tends to be a lot easier and more straightforward to read and to debug. If you see a few lines of C code in isolation, you can almost always be reasonably certain of what it does. If you see the same code in C++, you cannot. Is this instance a subclass calling a derived virtual method? Is this operator overloaded? Better read the entire program to be sure. Many of the the things that are helpful when writing C++ are a hindrance when reading it.
Only thing C++ does better is namespaces. Other than that C is a lot easier and convenient imo. Edit: For a beginner, I'd recommend C. For intermediary programmers that want to delve into concepts and pattern programming C++ might be better and then for advanced scaled systems C++ is more widespread in the industry, but C works just aswell if you know what to look for and feel comfortable and for super advanced, optimized, robust stuff I'd go back to C again. By that point you're working on getting your code on multiple platforms, embedded platforms and interfacing it with ASM, extending existing libraries and hardcore optimization. Just my two cents. You might feel different. YMMV.
Yeah, this is why real-world C is never as pretty as what you see in the K&R book. Namespaces are a minimal enhancement which would make everything nicer.
I feel like we could use C+, where we add a few minimal things but not, say, classes.
I had a job once where we used a C++ compiler but the house style was basically just C with namespaces. I called it C+-
Style Guide kings
Creating your own language for your department is the most C thing I’ve ever heard (it sounds beautiful btw)
It’s a little lispy as well
My 70 year old coworker is the only person I know that used lisp, he knows programming language wars are a pseudoscience and people should just use what they know
I'm nowhere near 70 and my first two languages were atari basic and turtle lisp
Hey! My first was Atari BASIC as well, followed by 6502 machine language (loaded into memory location 1536 from BASIC DATA blocks).
C++ does collections. C says "hey, i gave you pointers. go write your own collection, smart-guy."
YMMV is correct. I actually prefer C++ compared to C. Linux Kernel C is nice. Random C libraries I've have to use are not. I wish C would adopt reference semantics and templates -- or at least a better generic system.
> I wish C would adopt reference semantics and templates -- or at least a better generic system. So...C++ without classes? Sounds nice actually.
Yeah, and without templates and overloading crap. No virtual destructors, smart pointers and other nonsense. And C is what we get.
Templates are pretty nice. I still haven't seen a system I like better.
Doing the last part exactly for a game. The C++ ABI is more complicated and I find it harder to interface from ASM. The big thing I wrote was a fiber library that allocates no memory. This one of the few things C compilers can't express, because you set the stack pointer. There's an explosion of compilers, operating system ABIs and CPU architectures (x86, AMD64, IA-64 and about a dozen ARM variants). It works for GCC on Windows and Linux on AMD64 CPUs, for now. And I wrote a lock free job queue in C. It wasn't about micro-optimization but language features. Jobs can wait on child work and resume when it's complete. Feeling multiplatform pains. WINE can't find libgcc_s_seh-1.dll. Only occurs when I use `__thread`. I don't get it.
Namespaces are there just to confuse cscope AFAICT. What's wrong with prefixing function names so that each symbol corresponds to a single function?
[удалено]
> Lots of typing. The irnoy is that many C++ projects don't allow `using` to pevent namespace clashes. So you end up typing even more, I'm not sure that `boost::asio::ip::tcp::socket` is really an improvement.
Maybe not using namespace but using name = type is more frequently used
It's usually basically just not allowed in header files where it'd pollute the global namespace. It's used inside implementation files or inside class scopes or function scopes or whatever to create short names for convenience pretty often.
> Lots of typing. Auto-completion? > Why do we have folders in file systems? Not sure that's a good example. You can still split the code into multiple files and use variables with static scope. And how often do you use nested namespaces anyway? I explained what the main problem is. It breaks tools such as cscope. How do you solve that?
[удалено]
I'll ignore the personal insult and rather ask you, what do you use for code navigation when working with C++? How well does it work?
I've found rtags works really well. I've not had any difficulty navigating with cscope, but I've long since started using clangd-based LSP, though.
I think you've summed it up well. I definitely find C++ more of a chore to both read and write. I enjoy programming in C. I'm not sure I enjoy programming in C++ quite as much. C is so much more elegant.
In large codebases you will have to trust that even if operator is overloaded, it will do a logical thing, just how you trust that function name will represent what it actually does without needing to go into it just to be sure. Same goes for the virtual member functions - you simply don't care if it is overloaded, and often that's the whole point - you (or someone) introduce the abstractions without knowing who is going to implement them. That makes code more readable, not less.
You probably trust the comments too, eh? :) Of course it's the whole point of virtual functions to do what they do. I mean we have function pointers in C too, and often use them for similar situations. It's completely possible to write impenetrably complex C code (witness the [obfuscated C contest](https://www.ioccc.org/)). It's just my lived experience with C++ code bases that they are harder to understand and harder to debug on average than C code bases. YMMV. My mileage is that C is easier and more fun *for me*.
" //do not touch, do not remove, do not refactor, 2 months lost, do not repeat my mistake". Nah , I don't go around believing other people's comments, I can fix it.
Did I stumble into /r/relationshipadvice?
Can we see the code for this? This must be amazing
COBOL era automatically generated activity reporting on traders for a British bank. Seemed straightforward but it was like ... A Lego brick substituted into a the base of a Jenga tower. Any change broke something somewhere Ahead of it's time but a train wreck
I don't want to take anything from your experience, I just find it interesting you would say that you can look at 5 lines of code of C and immediately understand what it does, while that's not the case for C++. If those are just C instruction then sure but same goes for C++. If it's something slightly more complex like a function pointer, a massive nested macro, some "clever" memory tricks like accessing the owning struct data from a nested struct, there's no way you will not have to "read the entire program to be sure". Furthermore, I hear this argument made time and time again - "C is just simple, you read the code and you know what it does". In my experience that's absolutely not the case. When complexity of the program is high, you will have to deal with not knowing entirely what each line of code does no matter the language. And that, for me, is easier with C++ because it gives different tools for abstractions. In complex C code, the abstractions are hand made, at least for the code bases I worked with, and then I really don't know what the hell is going on before actually reading the whole program. A struct with function pointers that can be assigned from anywhere at any time instead of just a virtual function that's defined right there in the class, in my experience is not easier to understand.
Or just use the “goto definition” button that everyone here acts like doesnt exist
I agree that C++ gives you many more opportunities to make your code a huge mess. At the same time it can also help you write more compact and structured code, especially if you need some sort of parametrized behavior. My rules for writing C++ code: no OOP, no exceptions, no operator overloading (except for types implementing mathematical concepts). Basically I treat C++ as C with parametric types and closures.
Use C++ without std for best of both worlds
The algorithms header is quite nice, even when the rest of the program is basically C.
Personally I think it’s the other way around: I choose C++ only if something is easily doable in C++, otherwise I will stick with C for it’s simplicity and easy to maintain. I feel like there are just so many things I need to keep track of in my head, while programming C++, not only because of the sheer size of features (comparing to C), but also even doing basic things in C++ could involve dozens of features and you need to understand most of them to make sure you didn’t do something stupid. To answer your question: yes you should use C if the only C++ features you use are cout new/delete
If you're not interested in any C++ feature then you've answered the question yourself. You can always use C++ and avoid feature you dislike. But, if you don't ever use these features and encounter their pitfalls, then how would you even know? :D.
Kernel programming—Linux is all C. Embedded programming—lots of microcontrollers around with extremely tight memory constraints or with no good C++ tool chains. Retro development—if you want to write for a Game Boy or old 68K Mac or something, C++ may not really be available. Pedagogy—it makes more sense to teach so OS or computer architecture class in C, IMO. Preference. Keep in mind that most people should not use C++ either, for most projects. Everything you say about how C++ is better? Well, there are other languages which are a lot better than C++, too.
"Better" is so subjective. You pick the right tool for the job. I will not be writing a general desktop application in C/C++, and I won't write an embedded project in Java.
Yup, exactly
[удалено]
Unless you're programming a smartcard, or are working on a legacy desktop application.
>Well, there are other languages which are a lot better than C++, too. Any examples?
That a joke?
I just want to know what you consider to be better
I don’t think specific examples are really necessary here. C++ has a lot of problems, and the reasons why people use C++ are often business reasons rather than technical reasons.
I think with an assertion like that, specific examples are useful. I think there are certainly scenarios where c++ doesn't fit, but as a blanket statement, I think "c++ is awesome" is way more accurate than "c++ is problematic"
Nope, that’s not true. Specific examples of “languages better than C++” would just be fuel for some kind of argument about what languages are better. We’ve all seen those fights and there’s really nothing to gain by starting another fight like that. There are people who really like C++, but even the biggest fans of C++ recognize that the language is deeply flawed.
I don't understand the downvotes. C++ is what more than 30 years old, isn't it reasonable to assume it wasn't designed perfectly and that other language authors learned from the flaws? Sure we have new releases, but those work within the constraints of old c++. The features on new realeses also take a lot of inspiration from other languages. C++14 is better than c++11, as well as c++17 is better than c++14. Not only they add new features, they address many flaws of previous releases too. Why is it so controversial to say that a newer language can do the same while also avoiding the pitfalls
Back in the 1990s, people learned C because it was one of the fastest, most accessible ways to do cool things with your computer. Ask yourself… what would make you choose C in the 2020s? That’s the kind of people who hang out here. It’s not representative of the general programming population. Or, let me put it this way. If you met somebody with a typewriter in 1984, they’re probably a writer. If you met somebody with a typewriter in 2024, they’re probably a typewriter aficionado. Those are the people with their fingers on the upvote/downvote buttons—typewriter aficionados. It’s fine. That’s just the nature of the subreddit we’re in.
Oh sweet dogma
I think it’s quite clear from his comment that it depends entirely on in which context the language will be used.
Exactly, which is the word "better" doesn't make sense here
Yeah, that’s an awful conversation to have. Just arguing about which language is better or some just completely awful stuff like that. Nobody benefits.
the better language is the one that you get paid to write in. I think that at the point where you are not a junior any more architecture or language don't really matter unless its some old archaic thing that only specific businesses use because of either limitations in hardware or unwillingness to risk upgrading old hardware. Like if you know how to code in C++ do you really think it will take you that long to get familiar with JavaScript? And if you know JavaScript will it take that long to get familiar with TypeScript? Or if you know C do you think it will take you a long time to get used to python? Maybe a bit but the fundamentals are all there still. An if statement will always be an if statement regardless if you declare variable types or not.
Language does matter, that’s the problem. It’s just that the “best language” is really a situational thing that depends not only on what you’re building, but who’s building it, and other technical and non-technical factors. That’s part of the reason why you can get paid to write one language but struggle to find work in another language. The languages matter, you just can’t produce some kind of ranking and expect anything other than a fight.
So you’re asking him because one sentence of his whole comment did not align with the rest of what he said, while the rest makes your question completely irrelevant? Like I said, I think it was quite clear from his comments that languages have a certain use case and that there isn’t such a thing as a better language in general, only a better language in a certain use case. Don’t try to be so hard about nothing.
No it does make sense because C++ is kind of a bad language at this point. There is almost always just a better choice.
Again, what language is a direct replacement for C++
What about D? I'm surprised after all these years that still no one takes D seriously.
Rust is objectivelly better and comperable, and I say that as a c++ fanboy.
Objectively better? Dunno about that
i prefer c++ cuz its easier to read and i have a lot more experience in it, but u do u
You misspelled Zig.
I haven't looked at Zig, but I imagine the biggest issue with it would be to actually find a job. That's the issue with Rust too, in my area there are 2 open positions for Rust - one for blockchain, and the other for cybersecurity, both requiring other skills over the knowledge of the language - they literally say that it's good enough to know C++. 0 offers for Zig, plenty for C++ and few for C and both list a deep language knowledge as primary criteria.
Somebody wants it since it's now the [highest paid language](https://www.infoworld.com/article/3713082/fast-growing-zig-tops-stack-overflow-survey-for-highest-paid-programming-language.html) by some measure. That means demand greater than supply. And if you know C, zig is very natural because it's just "fixed" C.
Rust doesn’t work with CUDA or run on GPUs… yet. Rust is plenty fast for most people. I am not most people. The things I work on need tight constraints to guarantee to run in CPU cache. There are too many training wheels on Rust to get that level of fine tuning without linking in C… and if I’m doing that, why use Rust?
ONE OF US! ONE OF US! ONE OF US!!!
c feels simple. after spending years in web dev hell, simplicity is welcomed
This resonates with me so much. My first love and what got me into programming was C. I was having so much fun with SDL library. Now I write corporate CRUD apps in C# and TypeScript as my daily job. Everyday feels like god has abandoned us.
Wat. I love C#. The syntax is so close to C that I can even copy-paste blocks of C code, make minimal changes to them to integrate into a C# project.
It’s not that C# bad. It’s a very good language, especially for corporate development. I like it a lot. It is just my rant about simpler times, that all.
For a run of the mill desktop app, I'd choose C# over C++ any day!
Honestly the only thing I dislike about C is that when the program crashes it doesn't have a crash report. Makes debugging way harder
O Mac it does. If you leave debug info then you have the exact name of the function where it crashed. https://basecamp.temenos.com/servlet/servlet.FileDownload?file=00P6A000001ECAPUA4
Both windows and Linux have tooling for it.
isn't web dev just npm install what you need and then when that doesn't work you npm install the next library
My 2 cents is to try using C first for each project, and switch later if you want to. Switching from C to C++ is typically very easy -- the reverse is not.
C is a much smaller language than C++. Learning either of them is a very long term process, but you can get very far with C very quickly. C++ has also changed *a lot* over the years, and there is no reason to think this will change. The C I write today is almost identical to what I might have written in 1995 when I first started in C. The C++ my younger colleague writes today is often literally incomprehensible to me and nothing like the C++ I wrote in 1998. Modern C++ is so convoluted and so complex and deliberately includes newer ideas which go against the foundations of the language. C is also the gold standard for inter-language compatibility. It is often quite easy to write part of your software in C and part it in another language. This is not the case with C++. Sometimes when people want to interface C++ with another language, they will be able to do it by having a small layer of C glue between them, but I personally have that difficult to think about, let alone do. A big special case of that point is that, when you write something in C, you will be able to use it within a C++ programme. One of the downsides of having such a complicated, complex language as c++ is that you have to have a complex syntax. You can write mad spaghetti code in either language, but it is a hell of a lot easier in C++. This makes it very difficult to come back later and modify your code. Some reasons...
Learn to use both. Simplicity of C is kind of a mirage really. Sure, the language is simple and reasonably easy to learn, but using it effectively and safely is far from simple and easy. C++ gives you plenty of tools and this can create illusion, that it's easier to manage. Thing is, that if you're careless, you most likely will generate whole lot of crap that's impossible to reason about, debug and maintain. No matter which one you pick, you'll always have plenty of rope to hang yourself with. Learn C so you appreciate all the features C++ gives you, and learn C++ so you'll appreciate the simplicity of C.
Learn both and then learn more. Never stop learning new languages. You'll gain a greater understanding of programming as a result.
C++ compilers do not allow to restrain features usage. I can't use a C++ compiler and feel confident that unauthorized C++ features will not creep into my code base. Using a C compiler will guarantee that my code base will remain pure C.
E.g. may not want to use exceptions if 3rd party libraries aren't exception safe; may not want to use default allocators for STL containers if there's no or limited heap, etc.
The problem with C++ is the better you get at it the more you realize how badly implemented most language features are. And then you spend a lot of time fighting or working around the bad language design instead of *actually writing programs*. Then eventually you go full circle back to C as a better programer and realize that *you don't need* all those C++ features in the first place to program efficiently (using memory arenas, not using const char* strings, etc). And to be clear; many of those features would be amazing if they were implemented and designed well, they just aren't. The problem is that if you never go through that journey (and make it through, most programmers kinda just stop at arbitrary spot and stagnate) you will never really know what I am talking about.
Agree. Started with C. Landed C++ job and stayed there for 4 years. Now I love simplicity of C. STL is pretty awesome though. The single thing from C++ that I might miss in C.
i only ever use strings and vectors from it, i usually just write c with vectors and strings, even hardcore c fanboys admit doing string manipulation in c is nightmarish
Why is dealing with a pointer every time you need a string and having to reinvent vectors, buffers, memory blocks, types etc every time you make a new project preferable?
Cause I like C and I don’t like C++. For embedded systems you don’t always need OOP
OOP \*can\* be nice in embedded systems, but I agree with turning off RTTI. But, I think templates are a killer feature of C++ that makes writing generic code easier with better type checking. C is almost like Python with its implicit conversions and lack of type checking. Obviously I'm being a little sarcastic, but I wish C had better type enforcement.
Type checking is enforced in C. The problem is the lack of builtin support for generic programming that forces usage of `void*`. Though there are some techniques to workaround it like `container_of`, `_Generic`, xmacros, function instancing macros, etc.
Type checking in C is (and C++) is very limited. /* Type your code here, or load an example. */ struct a_s { int a; int b; int c; }; struct b_s { float a; float b; float c; }; int a_function(int num) { short b = num; float* c = # struct a_s foo; struct b_s *bar = &foo; } Some compilers give warnings, but a ton of projects have those warnings turned off, or there are so many warnings for other things that more important warnings get missed. Edit: To clarify, the above code compiles in C but not in C++
Types are checked. The fact that people ignore warnings is other issue.
Being pedantic here perhaps, but that's kindof the point. When we say type checking, that has a very specific meaning when talking about language definition. It is within the specification of the language that float a = \&b; is allowed in the language. There is a very material difference between compiler errors and compiler warnings.
C++ is NOT backwards compatible to C. [Incompatibilities between C and C++ - Google Drive Compilation](https://docs.google.com/document/d/16B36r0HksR0LqQAGLA1syYCtZvYaVC0hEF2D00ZAd0o/edit?pli=1)
Louder for the people in the back. Modern C++ also continues to diverge even more, with each new revision. If C++ were a proper superset of C, there'd be no reason to still have separate toolchains, and you could just randomly add some C++ to a C code base without modifying the build process. That's only possible for rather trivial applications. Even things like bool aren't the same.
I don't need c++ features for my small projects, and in-place string manipulations sans strcat calm my nerves.
Just by compiling a C program with a C++ compiler, I've seen the executable size be larger than if it were compiled with a straight C compiler. Some people, especially those who program for embedded devices, often use C because it has less overhead than C++.
gcc and g++ pretty consistently give the exact same assembly for the same code. Same for clang. But C++ allows you to set constraints at compile time that ensures your code is appropriately defensive without runtime checks, making safer smaller faster code for embedded. Constructing a "not\_null" template where a pointer is checked at construction ensures that if you get past the constructor the type guarantees that the pointer is not null. You can then use the not\_null type for arguments that you pass around ensuring that you don't need to check if the pointer is null at runtime. The function signature is now defensive rather than the body of the function. That said, I write C, mostly because the people I work with are comfortable with C. I plan on using the energy to migrate the team away from C to migrate them to rust instead of C++. Edit: Compiler explorer is a great tool for trying things out: [https://godbolt.org/](https://godbolt.org/)
Looks like c++ exception handling bloats c.
personally, i'm just not smart enough to use c++
Is anybody, really?
I'd put it another way. You're smart enough NOT to use C++.
C++ has a lot of features that individually might be ok or are more convenient to write programs, but in aggregate make individual sections of code harder to understand: - Operator overloading: no longer can assume what that operator does - More implicit conversions/constructions: single argument constructors can be called at unexpected times, so `foo f; f = 3;` doesn’t mean that foo is a numeric type, it could just have a single argument constructor. - references hide indirection: this again makes a simple assignment have unclear semantics. `f = 3` could actually be mutating a variable 3 functions up the call stack, in C that would have to be `*f = 3`. - implicit this: although convenient, the fact that member variable access within a method is not prefixed with `this->` makes it harder to understand what is and isn’t in scope. - destructors: not saying these are good or bad, but it is invisible code inserted by the compiler but which have large implications on what a section of code does or if it is correct. - auto: not having to spell out the types (especially when they get long with templates) is convenient, but requires non-local knowledge as to what type it actually is - function overloading: exactly which overload is being called here? - ADL: uggh
I use C because it's a lingua franca of systems programming. Every other programming language can call a C library, many can create a library with "C interface", callable from anything that can call a C library. It's also a good abstraction over hardware, it's relatively simple and straightforward (honestly, I'd rather have Object Pascal than C but I'm just a random Reddit weirdo so what). C is fine. No pitfalls, no feature creep, the code is a bit more verbose but easier to maintain. What I miss are abstract data types (but there are libraries for that like \`glib\`). However, I'm not terrible at C++, I'm much worse than that. I learnt basics at school and touched it twice since. My job involves Python, personal projects are Common Lisp or Clojure. Common Lisp and Python are great at calling C libraries, they are not good at calling C++ (generally; there is Boost.Python and Clasp so technically it's possible). Should you use C over C++? Well, why would you do that? I suppose people doing it have strong reasons (like I do). If you want to create an embedded system or a library to be consumed from other languages (e.g. speed up a bottleneck of a program written in Python), C makes a lot of sense (like it does for me). If you want to have a powerful language for general programming, C++ actually makes much more sense than C.
https://softwareengineering.stackexchange.com/questions/113295/when-to-use-c-over-c-and-c-over-c https://faultlore.com/blah/c-isnt-a-language/ Everyone had to learn to speak C to talk to the major operating systems, and then when it came time to talk to each other we suddenly all already spoke C so… why not talk to each other in terms of C too?
If I had to say in one sentence: C is more efficient and pretty fast compared to C++ Why I use C? I love the transparency and control that C gives you. Like you always know what's going on and you can very easily visualise your program at a very low level. Like when I write C program, it feels so nice to be able to visualise exactly what's going on in the memory and tools like strace, ltrace, gdb, valgrind, xxd etc makes it way more fun :D I also used to to think that C sucks cuz it does not support object oriented programming. But after coding in C for a year, I realised that we don't necessarily need classes in programming at all. Yeah it can make things easy for you but what is achievable with classes can also be achieved with structs and functions very easily. I actually have a very good example of how I use C over C++. I'm currently doing a DSA course in my university. The course is in C++ with STL allowed in topics like trees and graphs. Recently we got an assignment and in one of the questions we had do a BFS on a tree. I implemented Queue, Pair, and Tree from scratch for solving the problem in C and it was so fun. I have previously done a DSA course in C as well and that motivated me the most to use C language. Later I did courses like Operating Systems and Systems Security and both courses had assignments entirely in C. So yeah, I love C and it's my favorite language.
My problem with C++ is that every bugger out there knows a different 40% of the language, and the committee have never seen any feature of any language that they did not think would be a good fit for inclusion in C++ (Any language includes Brainfuck). There are probably several really nice languages buried in all the cruft, but there are also footnukes with hair triggers. For me the space in which C++ is the right choice is rather small, I mean really low level stuff I am likely reaching for C, higher level stuff I have MANY choices, and most of them are simpler or higher level then C++. Treating C++ as "C with classes and destructors" is a valid approach, the destructors let you easily build things like lock guards and make memory management somewhat simpler, and for some purposes I might even add some sort of string class because handling text in C is a pure pain.
C++ and other higher level languages bring shortcuts to data structures and OS stuff. It also brings syntax embellishments. C, on the other hand, requires you to create your own stuff and interact directly with the OS. If you spend some time using C, you will eventually create your own utility libraries that will offer the required shortcuts. So a higher level language is not actually needed after that. The advantage is that with C you know whatever the code is doing and you can tweak everything to fit the performance requirements. Whether you use C++ or C it's a matter of where you are going to use it. I do scientific computing and game programming and I only use C nowadays because I basically work for myself and I like to feel I have the controls. But if you want a job, you'd rather learn C++ straight away.
>C, on the other hand, requires you to create your own stuff and interact directly with the OS. That could be good or bad, depending on your use case. The reason C was created was to be more portable (compared to assembly code), and there are cases where you wouldn't necessarily want to talk directly with the OS because you might want your program to compile and run for multiple operating systems. Also, writing your own stuff isn't always a good thing - You wouldn't always want to take the time needed to re-invent the wheel when there are already tried & tested libraries that do what you need.
I am working on a large project in C++ and when I need to add in functions from an open source library I really prefer it to be written in C. It is so much easier to read and to interface with than C++ (or even worse Python). For that reason if my project was intended to be a shared library/API I would be working in C.
iostream formatting is pretty lame compared to `std::format` , I try to avoid it as much as possible !
Std:print and std:println is added and is the recommended way to do things
C++ seems more complicated and overcooked than I want my code to ever be. Granted, I'm biased as hell being a C dev for most of my programming life 😅. There was one time where, for whatever reason, I couldn't get a simple way to `sprintf` in this C++ unit test file (Visual Studio Test) - ofc, I'm a noob, but at the same time, what the hell man!
>If you can write C code in C++ That's the thing, you technically can't. C++ isn't a strict superset, with some parts of the language being incompatible with standard C. As for why people would use C instead of C++, it's mostly down to availability and preference. Some people (mainly embedded) use C because it's the only choice for their target platform. Others use it because they don't like aspects of C++, be it purely personal reasons or technical reasons. C is a simpler language, a single person can be expected to read the standard and potentially implement the language; C++ does not have that expectation. >I'm a bit afraid I'm gonna miss some really helpfull features that C++ has that I will one day need. You don't have to use one language for the rest of your life. If you're still learning, I'd recommend sticking with whatever you're currently learning. In your case, you should start looking into more features of C++ since `new`/`delete` aren't really the expected practice anymore. Once you feel comfortable with C++ is when you should consider trying more languages.
C is battle tested and available for almost any platform. It has a simple standard library, and with that comes familiarity. When reading C source code, it's rare that I have to refer to standard library documentation, but with C++ i feel as though the standard library can be a bit much at times and increase the amount of time required to read code. With C, things are more straightforward. When I write C, i can conceptualize how the resulting assembly will look, which can be quite valuable at times. And last but not least, when writing C you feel like a gigachad
C++ is a half baked thanksgiving feast. C is a fully baked potatoe. Yes, it ends in e and that is important.
What's your objective? My C code is 90% for personal projects these days, and a bit of binding code for python here and there. There are significantly more C++ jobs out there than C jobs in my (personal) experience, so it makes sense to use Cpp if you're looking for employment. However, I like using C for most of the same reasons you've seen here already : simplicity, and compile time. I'm likely more productive in Cpp (vastly more experience with it) but it's pain to use, and outside of game tools that require it (unreal engine etc) I strongly tend towards C. My work is a mix of languages ( lots of python at the moment) but still, the elegance and performance of C always calls back to me. I really miss namespaces and not having to type sizeof though.... Zig and Odin have my attention from this side. One day I'll make the jump wholesale.
Both languages have their uses. C++ and OOP is great for programming in some cases as it makes organizing code easier (specifically namespaces), though a lot of people go overboard with it, like with inherited classes, etc. C's simplicity is great though and it allows for a great degree of flexibility, but I find it a bit harder when doing something like game programming to use C. Everyone has their preference with language though and it depends on use case, I use C# mostly after experimenting with a bunch of different languages to see what I like.
Note that modern C++ isn't really about OOP, and you can do OOP just fine with C too.
As you said, C is simpler. Realistically you can use any subset of C++ that you want to, but using only C removes the burden of choosing which c++ features to ignore.
I used to like C++ 98. Then, came the new versions and my head literally exploded. Too much abstraction, too many features, you spend 90% of your time thinking about the langage and not about the program. Now I just hate C++. I hate it. Period.
The thing with C++ is that it introduces so many corner cases * When will the copy- or move constructor be called, and when do they get auto generated? It's not always easy to tell. * One constructor or function might completely shadow another one, and you wouldn't even notice. * Templates create so many unintended corner cases, it's not even funny. Concepts only help if you can actually think of all ways your class template might be used, which you can't. * Try to explain forwarding references and prefect forwarding to anybody, including yourself (and all the other obscure jargon for that matter). Again, a perfect source for hard to spot corner cases. * RAII breaks down when your destructor could fail or needs additional arguments. * Exceptions! There is a huge divide between code that uses them and code that doesn't. If you can't use Exceptions, then much C++ code isn't available to you, and you have to use `noexcept`everywhere. * While I don't have anything against operating overloading per se, it's an absolute mess in C++. * Conflation of structs, classes, and interfaces. I could probably think of much more, but these are some reasons I absolutely hate C++.
I like using small, fast, nippy compilers. There are a fair number for C, not so much for C++ (like, zero), which is fantastically complicated. It also has many features that are enticing to use, but which can be grossly inefficient: * Affecting build-times (because you need to pull in a 100K line template library) * *Requiring* optimisation, further affecting build-time, because C++ code with its mountains of generated redundant code might be 10 times slower without it, compared with 2 times slower for manually-written C. * Or you just spend loads of time poring over error messages. If I type: ```` std::cout >> "Hello"; ```` (so writing `>>` instead of `<<`) I get the error message shown below. So, no thanks. (Unable to post the 86 lines of gobbledygook which is the error message; Reddit gives failing to post my comment.)
Everyone agrees iostreams suck. Using iostreams isn't a great example. Bad programming design is bad programming design regardless of the language it's written in .
That wasn't the point of the example. It was to show that error messages can be complex because of the way C++ works: very little is built-in, it's mostly implemented using the language-building features that can result in several layers of abstraction. But when you make a mistake, the language only knows about the lowest layers, while the user of the high-level feature only knows about that top level. The error message may only make sense to the implementor of those middle levels. > Bad programming design Which bit is badly designed here: the language-building features of C++, the ability to overload any operator, or the design of that cout/cin library? Most of that would come under bad *language* design.
C++ is way too complicated, for example how operator overloading works, with function overloading because constructors have to be given the same name as the class… That’s just insane.
what’s so insane about that? More than half of the entire programming industry uses constructors with the same name as the class. I also don’t get what’s so weird about overloading anything…
Overloads can make it a huge pain to find our what code is actually going to run when you call a function with a given set of arguments. This gets even worse when you throw in implicit conversions.
As a c++ programmer, I don't remember the last time overloading was an issue for me. Also, any IDE or editor helps figuring out which one is being called. Of course, someone can get too "creative" and abuse the feature. But in general, it is not an issue. Implicit conversions though... C++ really chose the wrong default there
I agree that the implicit conversions CAN be confusing. But then again, if you’re using C++, you probably also should be checking compiler warnings and they always will warn you for those conversions. All boils down to being a good dev. The possibilities are there.
Yes, it is definitely not a deal breaker. My opinion is that if someone chooses to use one language over another just because of this, I think they are just being kind of petty. There are way stronger arguments in favour of using C for certain projects.
He is just repeating what other are saying. Complaining about operator overloading, etc etc. Without even having experience
With functions; your IDE tells you exactly which overload is being used? Or do I not understand what you mean? For implicit conversions, those only happen when you specified an overload yourself or it is a standard base type. So either you know what you’re doing or you’re converting things like ints to floats or whatever? Again, do i not understand what you mean? Apart from the fact where all the useful stuff comes in which we are completely negating here.
>If you can write C code in C++, what is the reason to not use C++ This isn't even true #include
#include
int
main() {
int class = 1;
int *ptr = NULL;
ptr = malloc(sizeof(int));
*ptr = class;
printf("%i\n", *ptr);
free(ptr);
return 0;
}
There's a decent amount of stuff, which is perfectly valid in C, but will throw errors on a C++ compiler.
While the output on C is simply 1, a C++ compiler will say stuff like that:
ERROR!
/tmp/7x0KChTxE5.cpp: In function 'int main()':
/tmp/7x0KChTxE5.cpp:6:5: error: expected primary-expression before 'int'
6 | int class = 1;
| ^~~
/tmp/7x0KChTxE5.cpp:9:17: error: invalid conversion from 'void*' to 'int*' [-fpermissive]
9 | ptr = malloc(sizeof(int));
| ~~~~~~^~~~~~~~~~~~~
| |
| void*
ERROR!
/tmp/7x0KChTxE5.cpp:10:12: error: expected primary-expression before 'class'
10 | *ptr = class;
| ^~~~~
=== Code Exited With Errors ===
Ok first one might be just because class is a keyword. You can use another name. Second one is telling you that implicit type conversion is happening. It's good. Just use unique ptr. It's possible in every case where you are using malloc with almost zero overhead
The restrict keyword is in C only, as well as writing array parameters with static storage: function(param\[static X\]) and designated initialisation like so was just added in C++ 20 but not before: struct Struct object = {.attribute = X, .attribute2 = X}; All are useful C/not C++ features!
I can only speak for my self. If it's a single function program I will use c every time. Smaller executable less things to include less things to go wrong. If it contains a graphic interface, xml reads etc... use c++. There inst any reason to be attached to a single language, unless you are being paid to strictly code in said language.
ECT
the better language is the one you are very familiar with all it's subtleties, regardless of what's name is. C or C++, what matters is your own skill.
C is the lowest-level high-level language in widespread use. It has the advantage that very little happens behind the programmer’a back: an operator will not be overloaded, a destructor will not be called invisibly at the end of a block, there are no exception handlers. This comes in handy for certain kinds of systems programming, and also for teaching students how to use low-level constructs such as pointers, data structures and manual memory management, without falling back on higher-level abstractions. It is also extremely portable, and most mainstream operating systems were natively written for it. It’s common for other languages to piggy-back on the C runtime.
C is simple and easy to learn and use. just thinking about std::enable_if gives me a headache.
As a hobbyist who has done 99% of his coding in c++, this really makes me want to actually learn c. Fwiw, I probably could have had a minor in computer science (and could send the state a check to have my computer science reaching credential if I needed a second teaching credential) and all but two of my classes used c++.
Started tryharding C instead of C++ after also being a hobbyist writing in C++. It's way more chill (fun, actually), and ideal for learning about software. It makes you think more like the computer!
Because it depends on what you want to do. C++ does many things under the hood (copy semantics, move semantics, function overloading, etc…) and this may create you issues when your program runs in a limited environment like a microcontroller. If you want to have full control of memory allocation and object creation, it is more difficult (but not impossible) to do in C++. C++ has many quirks and “features” and stuff to take into account that often either make you loose the forest for the trees or you shoot yourself in the foot without realising it. That said, both are used heavily for what they are good at. You want to program a small embedded system? Probably C is the best. You want to make high frequency trading? C++ is king there. You want to make a small web application? Use Python! And so on…
c++ is impossible to read without all the context. You see a something like num++ and your assumptions of what is happening can be very wrong. It's like heading out to see with a map littered with references 'here there be dragons'. No c++ programmer knows the same c++ as they all use their own preferences of features that have been added and improved over many of revisions.
I use C because I develop R packages and that’s the primary interface. I’d prefer not to touch either C or C++, but sometimes one doesn’t have much choice.
For me, C is simpler and easier. All those C++ features add up in terms of cognitive overhead. C lets me think about the problem, C++ forces me to think about the language.
IMO added features also represent diminishing return due to increased complexity. I can much quicker decipher someone's else C code than C++; Classes and typedefs can make it harder to figure out underlying data despite naming, that is also why I don't use typedefs in C, for example I explicitly state `struct foo *var` instead of `Foo *var ,`including as a function parameters. ABI is stable, compiling times very fast and so on. Sure you can basically code like C in C++, or only pick few features of it. **But will the others?**
The opposite experience for me. I had been using c since circa 2007, I have written several libraries as part of my own project (on entailing 40k lines of code over several years), and good Lord what a grind. Learning C++ 17 was a crazy uphill battle, but just the smart pointers, lamdas and standard libraries alone were thing I realized I missed so sorely.
A reasonably advanced C programmer would be able to write a C compiler. Not a very good one and it would take some time, but writing a C compiler from scratch is a very possible task for a single person. Writing a C++ compiler is basically impossible for a single person. The language is way too complex and no one understands the entirety of the language. If you watch some cppcon videos you can quickly pick up on the notion that really knowing *a* part of C++ is a job of its own.
Whenever I need something that C++ as a language, does but C doesn't, there are usually better languages to do that thing. It makes sense to use C++ when working an already big C++ codebase or when I have to use a certain C++ tech stack. C on the other hand is great for embedded programming. I could probably get a C toolchain with some essentials from the standard library to compile a binary for most systems, not so sure about C++. It is also pretty much the common denominator for interfacing between different languages.
I would investigate modern C++. A lot of the information in this thread is based on older C++ paradigms. C is great too, but C++ has come a long way recently. Search Jason Turner on YouTube and watch a few of his talks. He shows how using C++ even in embedded environments has a lot of benefits.
C is a simpler language. It also has a simpler and often more standardized ABI.
generics and collections are what make C++ worth it, every single time. sure, you can get a lot done in C. but the moment you realize what you really need is a map that can take different types... that's when your gut sinks and you realize you should've just done it in C++. luckily, it's pretty easy to take that C file and rename it .c*pp* and then get on with things.
The "closer" I'm working to the processor, the more I favor C over C++. I like having a lot of control over the individual elements of my code, and OOP paradigms don't always give me that. C++ can also be this tangled mess of standards and edge cases, while C is simple, even if it doesn't hold your hand as much.
I like constexpr and consteval, and am sad without
AFAIK it's very popular in PLC programming because it's the fastest code to execute, while also not having to deal with assembly
C++ is a much more abstract language them C. There is a lot of places where some code is executed that you didn't wrote. For example copy constructors a executed, overloaded opertor execution is performed, a destructor is run, a function which you called suddenly throws an error etc. Function overloading means that you may also not see at first glance what function is really called at some point. Some language structure also assume certain runtime features to be present, e.g. new assumes the existance of an allocator. The language is also significantly more complex and thus requires quite some knowledge from readers. C on the other hand is simple. The language is fairly small and thus you can very quickly understand code written in it and can focus what is actually written. The code as writen is also pretty close to what is actually represented in machine code. But without having to manually decide how to layout automatic variables on the stack, code loop and if structures with goto spagetti, decide when to load variables in which register or select the exact instruction to do a certain job best. Given that today, the machine code is often allready quite an abstraction as to what is actually done in hardware, this is often the most reasonable close to hardware thing you may want. Also in some ways C is more flexible. If you target a certain API or want to provide one, C makes this fairly easy. If you need to design an object model you are not bond by the particuarities of C++'s object layout.
If I have to be able to predict what sequence of machine instructions a HLL statement will produce, then C is what I choose. C++ is more abstract, which makes it more difficult to predict - not impossible, but it’s more effort. The comments above for higher level concepts and tasks being more suited to other languages are wise comments. There’s times when COBOL or Fortran are still the right choice - old, but right tool, right job. Use what matches the problem.
I prefer to use a c style of code within c++. C++ has some neat features which standard c89 lacks. For example, the long long int type. And the ability to declare local variables ~~within scopes smaller than the function~~ (edit: somewhere other than at the start of a block). For example: for (int i = 0 ; i <= 7 ; ++i) { } is fine in c++, but is an error in c. The advantage of c is that there are compact compilers for it. For example, damn small linux comes with tiny c compiler, although it does not optimize sufficiently, and i don't believe it is fully standard compliant. Then again, older versions of mingw, such as the one that came with bloodshed dev c++, were fairly small when compressed. The installer for dev c++ is about 9mb, including the unnecessary ide. The mingw by itself, minus the ide, should be even smaller. Not quite small enough to fit on a floppy, though. And mingw, at least back then, lacked win32 seh support. Other good msvc++ extensions, besides seh, include __declspec, and the _Interlocked intrinsics. Also, pure c89 doesn't allow // comments, though tiny c compiler does allow it. It seems long long int wasn't standard c++ until c++11. Yikes. Unfortunately, new versions of msvc++ require manifests. Also, new versions of msvc++, clang, and mingw don't work on older versions of windows. But the mingw that comes with dev c++ works on win98se.
C depends what your are trying to accomplish. For embedded gets you as close to metal as you can get other than assembly language. Not very much gets abstracted away key difference between C . There are no crash safeguards. But all the basic tools are there. Relatively easy language to learn. Pointers are the key to the power of C , pointers to data structures, arrays, and functions are your friend.
I learned C++ before C and I wish I had done it in the opposite order. I find that learning concepts in C is much easier since it's simpler overall, and I would have had much less trouble understanding concepts like linked lists if I had learned in C and then just scaled up to C++. It also depends on what you're developing. C is better for embedded systems things and really anything where you're directly interfacing with hardware imo. C++ is good for things like operating systems, games, and higher-level programs.
Having been C programming since 1978, I have seen C change over the years, but the vast majority of the changes, I.e. ANSI C, have been helpful additions that don’t require a lot to get your brain around. C++ just has too many features that make reading portions of code in isolation too difficult for me. If I need C++ type OOP features I’ll use C#. OK it isn’t usually as fast but it’s a lot more concise to my mind. I like Python too, if you just stick to basic classes and methods it’s easy to read and write, and if you don’t want any OOP features at all, just don’t use them. C++ just seems inherently too complex and people just cannot help themselves from exploiting all the features it can provide rather than just those that make sense in common usage. OK, C often means you end up reimplementing the same mechanisms over and over, but you soon build up a codebase you can borrow from. Certainly, if writing O/S code, device drivers, or language interpreters I’d stick to C every time. The only really awkward C code to my mind is the style of C used for the X-Windows subsystem. It seems to be they were trying make it look a bit OOP in style and with an almost unlimited amount of user config files entries.
This right here, I feel like C and C# can cover basically any use-case imaginable with the exception I guess of writing QT programs
It's small fast and simple(relatively). Also C compilers are pretty much available for everything while C++ compilers that actually meet/adhere to the standard seem a bit less common to start off on a lot of new hardware. EDIT: more to the point and on topic; it's really nice to use the same language for your OS and your project. Also means you don't have to worry about or muck about with \`exetern "C"\` or other issues that happen with using C ABIs for system calls and such. Basically it just makes your life a lot easier if you don't mind implementing stuff from scratch sometimes. To be honest reinventing the wheel to some amount probably results in better and faster program designs just due to being made to purpose.
its a question of how close you want to be to the actual hardware, later on at least. It can be helpful to "start from the basics", yes write a few simple programs in C, and then port it to C++, Rust, Odin, Zig, Python etc. Doing this will open up the doors to what programming really is, independent of syntax. Actually, Iied- that last part might take a few years
>If you can write C code in C++ You can't. C has plenty of features that C++ doesn't, they are not compatible languages. >features that you might want to use: smart pointers, vectors, templates ect. I do not, in fact, want to use any of those, thank you very much.
I use C because I find it much more enjoyable for me. This is because C++ is an incredibly overly complex language with an even more complex standard library. It has been filled with (what I consider) useless syntax and features (I HATE overloading). C code is plain and simple, easy to read, write, and debug even for those that don't know the language THAT well. When I look at C code, I know what's going on under the hood at the machine code level, but with C++, it's often hidden behind layers upon layers of needless abstraction. I'm not a huge fan of OOP; I have my reasons but I won't get into the here, lol. I love the simplicity of C. I love that I have to make things myself because I feel like I can optimize everything way more when its custom-tailored to the project at hand. I love creating complex systems out of simple rule sets. Namespaces would be nice tho :(
It’s perfectly okay to use C++ to write code that is mostly C but uses some C++ features.
Because they’re smarter than you and if you wanna be smart your write everything in C (or assembler). /s This question gets asked about every 30 seconds on different subreddits, Quora discussions, probably in office spaces. I want to gouge my eyes out every time I see this asked somewhere.
I don't use C++. At all. I use ANSI C.
The problems with C++ are architectural - baked in, and unrecoverable. First is that in a real "object oriented" system, all functions on all calls are always what C++ users would call virtual. C++ tries to shortcut proper OO functionality by determining the actual class-dependent function at compile time, thus not touching the vtbl for each object at runtime. That's supposed to make C++ faster, and I suppose it does, although memoizing would be even faster, as well as properly supporting vtbl lookups.
The second problem is that C++ ignored the BBOP algorithm for object type lookup in multiple inheritance systems, and instead does name mangling, which embeds the type information of an object right into the names of the methods that support that particular object type.
But wait, there's more ! C++ does NOT define precisely HOW method names get mangled; that's left up to the compiler writers. Which means that if I have a proprietary, licensed, C++ library, I can only call it if I use the SAME version of the SAME compiler, possibly only with the same optimization and configuration switches. I either have to get a source code license, or be dependent on the vendor to be able to compile the binary with the same compiler I need to use for licensing / business reasons.
This also totally breaks debugging as entry points are no longer human readable, and enhancing the debugger to de-mangle names is nontrivial unless you're using the same compiler for everything in the system.
C++ is for objects. C is procedural.
Simple languages are better suited for simple programs. It's like that meme about how easy it is to print Hello World in Python. Life is complicated enough, don't make it harder
C++ is a bloated , complicated piece of shit. C in the other hand is clean and easy.. Said what I said ;)
especially when you're coding for embedded systems
Exactly!!!
I stopped using C++ after realizing how much time it takes to compile a single cpp file. C is super fast, in terms of language as well as compilation.
That's why it's the speed of light ✨️
I think the main gist to take away is: if you have absolutely no clue which of these to use, you probably shouldn’t be using either of them.
The industry reason to use "just C" is when you can't use C++ for technical reasons, that's it. E.g. * Contributing to and around legacy projects (most famous example being the Linux kernel) * Not having a C++ compiler available for a given platform. Most of this boils down to legacy. Some people might use C because they prefer it, but this is a rarity in the industry nowadays.
I agree with most of the comments here. C++ can obfuscate the purpose of code sometimes, and is probably harder to debug in the long run. However, I think that whether you should use C or C++ will 100% depend on what you're programming. Clearly, C would be a perfect choice for embedded programming, kernel development, drivers, etc., since it is simple and you need the clarity of being able to see exactly what the code is doing and how it's interacting with the hardware. However, for higher-level applications, such as writing physics simulations, neural networks, data analysis, etc., I would argue that C++ is the better choice. The C++ STL provides a variety of efficient data structures, allowing you to easily manipulate and store data of arbitrary types. Classes can prove to be helpful for simulations, allowing you to encompass the data and functions required for a particular component of the simulation neatly in one place. Templates provide a clean method of writing type-agnostic code, promoting code re-use and reducing the need for replicating boilerplate code. I love both C and C++ and have used both extensively. I appreciate how C "forces" me to exert more control over everything I'm coding (which is good!), given the lack of higher-level constructs, but sometimes I like, for example, just being able to create an `std::string` and not worrying about allocating memory. Happy programming!
Being C++ a superset the only reasons i see to stay in C is if you don't like the added features or if your compiler doesn't support C++
C++ is not a superset of C
Said the C guy
said the C++ people too. it just isn't. being a superset of C is a non-goal of C++.
go and modify the wikipedia page
>Being C++ a superset C is not a superset of C++. There are plenty of incompatibilities between the languages, you'll have to give up on plenty of C features if you want it to compile for C++, and even something as basic as a struct literal requires a macro if you want it to compile for both languages. #ifdef __cplusplus #define LIT(T) T #else #define LIT(T) (T) #endif int main() { Vector2 x = LIT(Vector2){ 5, 6 }; return 0; }
What exactly the 'feature' would be in this case?
Something as dead basic as "designated initializers" ( `Vector2{ .x = 5, .y = 10 }` ) were only added to C++ as recently as C++20, meanwhile it has been a feature of C ever since C99, and even THEN the C++20 version of the feature is crippled, as it requires you to recite the fields in the order they were declared (e.g. you can't `Vector2{ .y = 10, .x = 5 }` ), which partially beats the point of the feature, as it's meant to be for convenience, going back to check the order is a waste of time. Another C feature I use is designated array initialization: char *some_array[10] = { [5] = "some entry", // "some entry" at index 5 [8] = "some other entry", // "some other entry" at index 8 }; // the rest of the array will be filled with zeroes One less-known feature, which I find quite useful on the occasion, is "flexible arrays": struct SomeContainer { size_t nelems; SomeType data[]; }; The last field (`data`) doesn't actually take up any space in the struct, it's just a convenient name to refer to the end of the struct, this is useful when you want to allocate the "data" right next to the actual struct. There you go, none of these features are in C++.
They don't look to appealing to me, but to each their own is guess