5 ms·

These kinds of ridiculous statements poison the discussion and make it devolve into a complete mess. Stop that! 1) C is very difficult to use correctly even wi

by blub 11y ago

These kinds of ridiculous statements poison the discussion and make it devolve into a complete mess. Stop that! 1) C is very difficult to use correctly even with the best guidelines and intentions. My best bet for avoiding memory errors is being super-careful (read: super-slow) AND using static analysis AND using Valgrind to check afterwards. The last two steps are mandatory. Contrast this with C++, where just by using smart pointers, vector and array I can eliminate a whole bunch of typical C errors. 2) Scripting languages solve different problems than C++. The typical C++ tasks can't be performed by your programmer with 2 years of experience no more than they could by the same programmer if they had 40 years of experience.

ArkyBeagle 11y ago
Static analysis and Valgrind are wonderful. This being said, I think I was six months into using 'C' when I mostly stopped having memory errors. Mainly, you construct the operations against memory objects based on building up series of constraints. This is less trouble than it sounds. You learn to conform to the expectations of the language and libraries. And you use less of 'C' than there is to use. And when things get past a certain level of complexity, I tend towards making them state machines. Should you have to do that? I have no idea. I do agree that based on most other people's 'C' code, it does appear to be painful for a great many people.
- blub 11y ago
  Do you have some example? I can't really picture the series of constraints that you mentioned...
  - lfowles 11y ago
    Probably manual RAII. That seems to be where most stable C codebases end up, with a simple object model.
  - ArkyBeagle 11y ago
    RAII type things are part of it. The rest is simply making sure all the constraints are met. The fewer operational constraints, the better. For text I/O parsing, just be semi formal about it at least. Check your indices, be careful of integer overflow and be judicious in the use of floating point. Use block I/O instead of the finer-grained things in stdio.h . Have instrumentation built in that you can enable to capture test vectors ( if you have the resources ). Error counters can tell you a lot. the mechanism of choice for managing complexity tends towards state machines and sometimes message passing. That's a start.

by blub 11y ago

ArkyBeagle 11y ago

Static analysis and Valgrind are wonderful. This being said, I think I was six months into using 'C' when I mostly stopped having memory errors. Mainly, you construct the operations against memory objects based on building up series of constraints. This is less trouble than it sounds. You learn to conform to the expectations of the language and libraries. And you use less of 'C' than there is to use. And when things get past a certain level of complexity, I tend towards making them state machines. Should you have to do that? I have no idea. I do agree that based on most other people's 'C' code, it does appear to be painful for a great many people.

blub 11y ago
Do you have some example? I can't really picture the series of constraints that you mentioned...
- lfowles 11y ago
  Probably manual RAII. That seems to be where most stable C codebases end up, with a simple object model.
- ArkyBeagle 11y ago
  RAII type things are part of it. The rest is simply making sure all the constraints are met. The fewer operational constraints, the better. For text I/O parsing, just be semi formal about it at least. Check your indices, be careful of integer overflow and be judicious in the use of floating point. Use block I/O instead of the finer-grained things in stdio.h . Have instrumentation built in that you can enable to capture test vectors ( if you have the resources ). Error counters can tell you a lot. the mechanism of choice for managing complexity tends towards state machines and sometimes message passing. That's a start.