4 ms·

As if it were yesterday. Late 89 or early 90, I was learning my first programming language properly (after Logo, BASIC and other stuff). It was C. Common wisdom

As if it were yesterday. Late 89 or early 90, I was learning my first programming language properly (after Logo, BASIC and other stuff). It was C. Common wisdom was that C was bloat and you'd do everything in assembly anyways. I stuck to it (did asm as well). Then, a few years later everything changed with real bloat that was C++ of ye olde and C was back in full force and never quit being there. I've dabbled with C++ before STL craze and never went into it as some of my friends did, but it wasn't quite different. Just a different mental model that it evangelised. These days, I can't even tell what's going on when looking at modern C++. I'm not sure I even want to. C just works for me, and has for a long time. I've worked in numerous languages and platforms, even changed careers from programming (graphics) to film and television. But I'll always be a C programmer.

retro64 10y ago
I have been coding in straight C lately on an embedded personal project and have loved it immensely. I know what is going on and have a good shot at predicting the resulting assembly. However, for me, C falls down on large projects. I know there a lot of hate on objects lately, but the complexity of a project decreases while the maintainability increases when you use properly designed interfaces. You “force” the new guy to do it right because the interface makes it obvious. I know there are ways to enforce encapsulation with C, but I’ve never worked on a (large) codebase where this has been successful.
- Keyframe 10y ago
  Objects are in C as well, with structures. You can do abstraction like that in different ways in comparison to classes. For example, components are common. Difference being that objects are components, but not all components are objects. Also function objects, aka functors. I try to organize into specific components and piece them together into a sequential or threaded or both model, depending on what I do. Of course, it is specific to what I do. But there are large C projects that are successful - for example, Linux kernel.
  - pjmlp 10y ago
    And yet, in spite of all code reviews, they just got an use after free exploit this week and the CVE database is full of exploits due to memory corruption.
CyberDildonics 10y ago
I've encountered a lot of C programmers who feel that C++ is silly nonsense. C++11 really does put that to rest. Move semantics basically enable complete avoidance of manual memory management. There are many other powerful and convenient aspects, but in C++11 and on managing memory essentially goes away. I essentially never allocate memory explicitly.
- Keyframe 10y ago
  I essentially never allocate memory explicitly Depends on what you do, I guess. I process huge image sequences and have them run (play at least) in real time. I cannot afford to not allocate memory manually. In fact, I have to and I have to manage heap myself. I also have to manage thread affinity, in order to have threads (producer/consumer) share L2 cache to get the speed I want, and all that on multiple processors. Sometimes you must do that manually.
  - CyberDildonics 10y ago
    > Sometimes you must do that manually. You say that, but I deal with almost the exact same things. What I mean by manual is something like malloc where the freeing of memory is manual. Sean Parent would call this 'no raw pointers'. For starters, the fact that memory allocation is even an issue seems odd to me, I'm not sure why you wouldn't allocate large chunks of memory rarely. Even if there are OS specific calls I'm making to deal with special memory, I make sure it is wrapped with some simple class or struct that has a destructor and likely a move constructor. Alignment issues can be wrapped as well, then there is no doubt who owns the memory, who frees it, and where/when it is freed. I've never seen a situation in which raw malloc/free are necessary or any control is lost using C++. I doubt you suddenly want to use C++ still, I'm willing to bet you know C extremely well, but at least realize that your choices are not based off of technical reasons.
    - Keyframe 10y ago
      Oh, I malloc from OS or hardware (external custom hardware) rarely. Usually once, a big chunk at the start and then heap manage manually. Well, semi-manually too since I took most of my idioms into a library of mine. I had a lapse of thought. Keeping everything aligned is not an issue these days. Affinity can also be done from other languages if OS supports it (looking at you, MacOS), intrinsics or asm directly also, etc. One thing is sure though. You're right most of reasons aren't technical. I'm very confident about what I know and what I don't know in C and I don't have to second-guess (usually) what I want to do, because my experience lies with C. It's a subjective choice, but also a technical - since that knowledge and experience is my technical asset. It's not like you can't do something in C that you can't do in C++. In fact, you can do it almost the same if you want to, but with C++ you would be a better fit if you follow C++ idioms, which I haven't picked up over the years (especially after STL cambrian explosion) and something I think I won't in the near future. Reason is simple. Everything I do, I do mostly alone and so far C has been good to me. I venture into other things, out of curiosity and sometimes necessity, but I always kind of fall back to C. Sometimes it's due to the fact that I know of top of my head how to do something quick (which I often need to) without resorting to googling or I don't know how to make it run quick enough since I'm not intimate with the language (not C++ in this case, but in general).

retro64 10y ago

I have been coding in straight C lately on an embedded personal project and have loved it immensely. I know what is going on and have a good shot at predicting the resulting assembly. However, for me, C falls down on large projects. I know there a lot of hate on objects lately, but the complexity of a project decreases while the maintainability increases when you use properly designed interfaces. You “force” the new guy to do it right because the interface makes it obvious. I know there are ways to enforce encapsulation with C, but I’ve never worked on a (large) codebase where this has been successful.

Keyframe 10y ago
Objects are in C as well, with structures. You can do abstraction like that in different ways in comparison to classes. For example, components are common. Difference being that objects are components, but not all components are objects. Also function objects, aka functors. I try to organize into specific components and piece them together into a sequential or threaded or both model, depending on what I do. Of course, it is specific to what I do. But there are large C projects that are successful - for example, Linux kernel.
- pjmlp 10y ago
  And yet, in spite of all code reviews, they just got an use after free exploit this week and the CVE database is full of exploits due to memory corruption.

CyberDildonics 10y ago

I've encountered a lot of C programmers who feel that C++ is silly nonsense. C++11 really does put that to rest. Move semantics basically enable complete avoidance of manual memory management. There are many other powerful and convenient aspects, but in C++11 and on managing memory essentially goes away. I essentially never allocate memory explicitly.

Keyframe 10y ago
I essentially never allocate memory explicitly Depends on what you do, I guess. I process huge image sequences and have them run (play at least) in real time. I cannot afford to not allocate memory manually. In fact, I have to and I have to manage heap myself. I also have to manage thread affinity, in order to have threads (producer/consumer) share L2 cache to get the speed I want, and all that on multiple processors. Sometimes you must do that manually.
- CyberDildonics 10y ago
  > Sometimes you must do that manually. You say that, but I deal with almost the exact same things. What I mean by manual is something like malloc where the freeing of memory is manual. Sean Parent would call this 'no raw pointers'. For starters, the fact that memory allocation is even an issue seems odd to me, I'm not sure why you wouldn't allocate large chunks of memory rarely. Even if there are OS specific calls I'm making to deal with special memory, I make sure it is wrapped with some simple class or struct that has a destructor and likely a move constructor. Alignment issues can be wrapped as well, then there is no doubt who owns the memory, who frees it, and where/when it is freed. I've never seen a situation in which raw malloc/free are necessary or any control is lost using C++. I doubt you suddenly want to use C++ still, I'm willing to bet you know C extremely well, but at least realize that your choices are not based off of technical reasons.
  - Keyframe 10y ago
    Oh, I malloc from OS or hardware (external custom hardware) rarely. Usually once, a big chunk at the start and then heap manage manually. Well, semi-manually too since I took most of my idioms into a library of mine. I had a lapse of thought. Keeping everything aligned is not an issue these days. Affinity can also be done from other languages if OS supports it (looking at you, MacOS), intrinsics or asm directly also, etc. One thing is sure though. You're right most of reasons aren't technical. I'm very confident about what I know and what I don't know in C and I don't have to second-guess (usually) what I want to do, because my experience lies with C. It's a subjective choice, but also a technical - since that knowledge and experience is my technical asset. It's not like you can't do something in C that you can't do in C++. In fact, you can do it almost the same if you want to, but with C++ you would be a better fit if you follow C++ idioms, which I haven't picked up over the years (especially after STL cambrian explosion) and something I think I won't in the near future. Reason is simple. Everything I do, I do mostly alone and so far C has been good to me. I venture into other things, out of curiosity and sometimes necessity, but I always kind of fall back to C. Sometimes it's due to the fact that I know of top of my head how to do something quick (which I often need to) without resorting to googling or I don't know how to make it run quick enough since I'm not intimate with the language (not C++ in this case, but in general).