Do You Like C or C++ More ? #programming #coding #lowcode

48 thoughts on “Do You Like C or C++ More ? #programming #coding #lowcode”

• Yeah it's a skill issue.
  I can spend hours looking how a new structure compiles and behaves before I start using it.
  You just not supposed to use in c++ something you don't understand how it compiles and works.

• As a C/C++ software engineer I agree

• Many people told me Im the smartest guy that they ever met. So I bought an Unreal Engine C++ course, but the only thing I learned was that they lied to me.

• I like C++ more as long as it's used for the initial goal of "C with classes"

• what about zig? :=

• If only C had generics 😢

• Is C# similar to C and as useful?

• Doing that stuff "I know this line of code do" exactly on another level man

• You must hate Python then 😀

• i usually prefer c but sometimes i write some damn fine c++ that feels pretty nice

• For my projets i do a c++ file but i use c stuff

• Yeah. you can tell exactly what each line of code does. Until you increment your pointer one too many times, or index your array out of bounds, or forget to free your memory because you introduced an early return. Or when you accidentally cast to the wrong pointer type. Or when you double free your memory. Or when you put user input into printf and have ACE as a result.

  C++ provides safety that you simply don't get with c. Iterators and smart pointers and classes with destructors that free allocated resources like files or sockets can make sure that you can't use them wrong. Specific casts give you safety when you change the data types later on. Doing everything manually also involves writing everything yourself. People smarter than you or me have created the c++ standard library to be robust, free of errors and do exactly what you want, where a naive approach that you or I could come up with probably contains undefined behavior or other bugs in some edge cases. A simple function that calculates the midpoint between two values alone is worth a 1 hour talk if you want to do it right.

  Nevermind all the convenience features of c++, like function overloading, namespaces or templates that prevent you from going insane because you can't remember if you wanted the function version with the s at the start or the n at the end or maybe s and n?

  C is a field of landmines. And while c++ has the same landmines as c does (because of compatibility), it offers a nice, paved road around the minefield that usually is also a shorter and faster path.

  Why should I care to implement a linked list with structs for nodes and pointers and then create global namespace functions that can add or remove nodes and then continue to write a custom sorting algorithm for it myself. I want to use a list, not have a computer science class on how lists can be implemented. It's a fun exercise but not practical. That's why c++ offers the standard library in the first place, so you don't have to rewrite such very common things every project.

  And oh no, you changed your mind and don't want to use a list anymore but instead replace it with an unordered set that can't contain duplicates? Well, in c++ it's changing one line of code.

  c++ enables faster development of code with often the same or even better performance of the equivalent c code, is safer and if you really need it, and you rarely do, can go as low level as you want with your memory and bit manipulations. I don't need to know how std::unique pointer works, although I do. I only need to know that it works, and the limitations and then I can use it and be done with it. No more memory leaks. And I also know that it's literally the same assembly code generation than doing it manually. There is literally 0 cost, but potentially life saving benefits, certainly benefits enough not have to spend hours in the debugger.

  You c people are insane for using c when c++ offers backwards compatibility but also so much more on top of it. 99% of your bug prone, low level, manual, do-everything-yourself code would literally compile and do the same thing with c++.

  As far as readability goes, I prefer

  int sum = std::accumulate(v.begin(), v.end(), 0);

  over

  int sum = 0;
  for (int i = 0; i < sizeof(array); i++)
  {
  sum += array[i];
  }

  where sizeof(array) may not be valid if array is a function argument, requiring an extra argument, making the function easier to use wrong and also more cumbersome to work with.

  Or

  std::string a = "Hello";
  std::string b = " World!"
  std::string c = a + b;

  over

  char a[] = "Hello";
  char b[] = " World!";
  char c[64] = {0}; // magic number, wasted space, wasted effort if you calculate to fit exactly, potential error if a or b change.
  strncpy(c, a, sizeof(c));
  strncat(c, b, sizeof(c));

  where the c++ version is straight forward, easy to read, and error free 100% of the time, and c is cumbersome, hard to read, and full of potential errors. For example I almost used sizeof(a) for strncat.

• I'm neither a C nor a C++ developer but I've never seen someone unequivocally claiming that C++ is better than C which makes sense because C++ is a superset of C. I did, however, see a lot of experienced developers who praise C and talk about all the negatives that come along with C++ which I also understand since I'm a not a fan of OOP or any convoluted abstractions wherein lies all the confusion and problems.

• Couldn't agree more – if a language spec does not fit in your head you can not predict what the compiler does and what the resulting program will do. And C++ spec is what now? 1500+ pages?
  Have seen 15+yr developers yelling at each other just to find out that they use different subsets of C++ to solve problems…

• I really feel you, I tried a lot of programming languages and when I had to decide whether I stick with C or C++, I instantly choose C just because as you mentioned in C++ sometimes it’s really hard to decipher the real purpose of a specific line of code. When you think you know C++, the language just kindly presents you the fact that you don’t know anything.

• You're obviously correct. You read C, you know what it does, C++ not so much. But that's the thing with OOP and higher level. That's the point. You don't really care to know how a tire is made. You just wanna use a tire to swap it for your flat tire in your car. In the same way, I don't wanna build a doubly linked list in C yet again, I'd rather just use something like a C++ std::list or whatever suits my problem.

• I like C++ but I'm pretty judicious in my use. Operator overloading is really nice if you're dealing with mathematical types e.g. arbitrary precision numbers

• Mangled names is the problem with C++ in embedded system. Source code inheritance is horrible too. The community is bad. The smarty pants are good, but when you run into a bad C++ programmer, don't even try to fix it. Just take their code and trash it and start over.

• and in C you'd have to call it "calculate_difference"… and it still can do heap allocations

• I understand your point, because I have seen some C++ code before and sometimes it looks like a completely different language and I always need some kind of translator to see what's going on. But, if you write C++ code like C, you get to use all the new features of C++ without having to worry about installing a third-party library or straight up building it yourself.

• This in general is a "problem" with abstraction. You trade code that is more traditionally readable and more concise for not immediately knowing low level details of what does what.
  Which is better is very dependant on the use case and personal preference.
  For most sub millisecond usecases I've had to deal with when writing stuff with C++ using some linear algebra library that does operator overloading it was more than fast enough for the job while making it just easier to write simple vector and matrix maths.

• What do you mean by minus sign doing heap allocation?

• Skill issue

• I like C (or C-like C++) because it’s dead simple and rarely distracting. There is no polymorphism, inheritance, method overriding and function overloading, interfaces, virtual methods and classes, concepts and constraints, exceptions, encapsulation, RAII, parametric polymorphism, life times, move semantics, and so on.

• Based

• I couldn't agree more.

• Couldn't agree more. C++ results in precisely the opposite to all the claims it makes. Jump into any non-trivial c++ codebase and good luck figuring out what the fuck is going on. EVERYTHING is obfuscated (they say abstraction, they do obfuscation). It's nigh on impossible to reason about any program larger than "hello world" and even THAT is doing a million things in secret behind your back.

• How do u work with strings in C?

• That is a very not skill issue thing. That's just not being a garbage programmer.

• So, you dislike bad C++

• I like c++ ❤❤

• Skill issue

• So basically you prefer what you know. As most people does.

• The minus sign can do heap allocations? I don't think that's true, but I could be wrong. I mostly program in C these days.

• you can say the same about rust

• Best open source projects to learn??

• Abstractions are good actually 😊

• There is a lot of code overhead needed to handle classes in C++, in comparison to C. So, as for myself, I recognize what my C code would roughly look like in assembly. C++ code, not so much. High level languages didn’t really click for me until I learned assembly. It’s why I’ve been following your channel, LOW LEVEL LEARNING.

• People say you can simply avoid using the ugly parts of C++. The problem is that you still have to read and use code written by people who DO use those features.

• I really love C.
  It was the first language I learned.
  I love it because, when writing an application, you start from the basics, doing everything until you create complex software; this helps develop the programmer's knowledge. Unlike others, which have some pre-made functionalities, what you do next is pick and use.

  Although I love Python and JavaScript!

• With macros, every C++ project becomes it's own programming language.

• Language readability is only one aspect of several factors you should consider when choosing a language.

• In my personal projects I generally just create cpp files but write mostly C code and occasionally use C++ features where I need them and where I see a clear benefit over C counterparts. That's also why I really LIKE C++. You (mostly) aren't forced to use C++ features. Theoretically if someone really wanted, they could write a program in C++ but only using C features without anything from C++. Also I think there are good uses for both C and C++. For example when I'm writing more low level stuff (like drivers, internal os stuff etc) I like to use C. But for example when I'm writing code for games or stuff with UI, I prefer C++ and the OOP aproach instead of functional. This is my personal opinion, but writing game stuff or UI stuff not in OOP is pain, and on the other hand writing low level stuff in OOP is pain too, so I think everything has it's own use cases

• Cpp syntax is horrible imo. Operator overloading is terrible as well. Cpp is just abstracted c

• C++ is great *IF* you (and the code you are working with) stick to the standard and follow best practices for modern C++ (i.e. C++11 onward). Pre-C++11 was a nightmare and people who still code like that should just stop plz

• skill issue :/

• Yeah, I remember a professor in my time (early 1990) at the University who was adamantly agains using computers to calculate math models. His point was you should only use logarithmic ruler b/c he didn't understand how to use computers to do that. So, the fact that you don't understand C++ and don't like it – means only one thing – that you don't understand C++ and therefor don't like it.

• My first language was c++. Then i got curious about operating systems and started looking at kernel code. So i started experimenting in c. Havent turned back. I still write my c in kind of oo style but i feel the library in c++ is too expansive and hides too much unfer abstraction. Also less readible for me.

Comments are closed.