3 ms·

Some more clues where this comes from are in this issue: https://github.com/DaveGamble/cJSON/issues/255 https://github.com/DaveGamble/cJSON/issues/255

by avian 6y ago

IshKebab 6y ago
Pretty good advert for not writing code in C.
- GuB-42 6y ago
  More like writing C properly. When you program in C, you should know exactly what each byte of memory is for. If you don't do that, not only you will eventually get crashes and leaks and overflows, but you also miss the point of programming in C in the first place. C is fast, but C is not fast because it overclocks your CPU or whatever magic you can think of. An good reason why is is fast is that it gives you tight control over your memory. You can reuse buffers, size them precisely, allocate them exactly when you need them and free them when you are finished, nothing funny happening behind your back. It generally results in lower memory usage, better use of cache and therefore better performance. If you don't manage your memory precisely, then sure, C is probably not the language for you.
  - harry8 6y ago
    >If you don't manage your memory precisely, then sure, C is probably not the language for you. I agree with everything above that line and probably the intent of that line too. However I'd phrase it as: If you don't want to be forced to make a large effort managing memory for the given task, C is the wrong tool for that job. Even when you're great with C. Even when C is wonderful for a different job because you do it fabulously well. I use C and like it. I don't use it when python is good enough for the job because in those situations python is likely to be actually better than C because you'd incur a debt to pay for something you don't need and as a result you just might miss one of those payments. The interest rate on a missed payment can get pretty steep. Prefer shell, ruby, perl, something jvm, whatever? - Great. Exactly the same point applies. I'm sure this point does /not/ apply to your comment above but it could be (mis)interepreted that way - C programming macho arrogance is not helpful for good quality software. C macho arrogance is pretty destructive, in fact and IMHO the worst thing about the use C (& C++ etc.)
    - GuB-42 6y ago
      It was the intent of that line and I totally agree with your comment. C is definitely not the right tool for every job. And in fact, I don't write that much C for that reason, the cognitive load of tracking every bit of memory is high and not always justified. I wouldn't put C and "modern" C++ in the same class though. They are actually very different from a memory management perspective. You can write C++ like you write C, there are plenty of valid use cases for that. However, the "standard" way of doing C++ now implies things like containers, RAII and smart pointers. It means objects get allocated and de-allocated automatically, dangling pointers and buffer overflows are less likely, but it has a cost in terms of performance and control. Another tool for another job.
      - harry8 6y ago
        Yeah totally, completely agree. One of the things C and Modern idiomatic C++ (using C++11 on) have in common is some part of the culture surrounding them having a tolerance for, if not liking of, macho arrogance. "If you got burned it's purely because you're stupid and lazy which I am not, ha ha." This kind of vibe. Not everywhere by any means, but it exists and it's destructive to sensible analysis and the writing of good quality software, while alienating some talent from the pool of potential colleagues. I strongly dislike it.
  - throw_m239339 6y ago
    > If you don't manage your memory precisely, then sure, C is probably not the language for you. > More like writing C properly. A lot of C problems could have been solved within the language without adding any kind of advanced CompSci construct. C is fundamentally outdated as a language and rely on assumptions and restrictions from the 70s. Unfortunately each time someone wants to replace C, they stuff the remplacements with the unnecessary evolved constructs I talked about. A language shouldn't need to be "written properly". Manual memory management doesn't have to be hard at first place, it is made hard by C weakly typed nature and horrid syntax.
    - bcrl 6y ago
      My personal feeling is that the compiler writers have gone overboard in their literal interpretation of "undefined behaviour". C on any real world machine has quite well defined (and expected) behaviour. In the real world we don't expect to have to support 6 bit or 18 bit CPUs today. Numbers are stored in binary, not trinary. The C spec should really be tightened up to define a lot of what was left undefined for these relics of history. The worst example of undefined behaviour abuse by a compiler is when gcc developers decided it was a good idea to optimize away a NULL pointer check just because the pointer was dereferenced. Seriously? Sometimes I really wonder who comes up with the idea that removing code the developer wrote is OK, but I guess that's the primary goal of any optimizing compiler.
  - IshKebab 6y ago
    The point is that nobody does manage their memory "precisely". Everyone makes mistakes and in C those mistakes are fatal.

Some more clues where this comes from are in this issue: https://github.com/DaveGamble/cJSON/issues/255 https://github.com/DaveGamble/cJSON/issues/255

by avian 6y ago

Some more clues where this comes from are in this issue: https://github.com/DaveGamble/cJSON/issues/255 https://github.com/DaveGamble/cJSON/issues/255

IshKebab 6y ago

Pretty good advert for not writing code in C.

GuB-42 6y ago
More like writing C properly. When you program in C, you should know exactly what each byte of memory is for. If you don't do that, not only you will eventually get crashes and leaks and overflows, but you also miss the point of programming in C in the first place. C is fast, but C is not fast because it overclocks your CPU or whatever magic you can think of. An good reason why is is fast is that it gives you tight control over your memory. You can reuse buffers, size them precisely, allocate them exactly when you need them and free them when you are finished, nothing funny happening behind your back. It generally results in lower memory usage, better use of cache and therefore better performance. If you don't manage your memory precisely, then sure, C is probably not the language for you.
- harry8 6y ago
  >If you don't manage your memory precisely, then sure, C is probably not the language for you. I agree with everything above that line and probably the intent of that line too. However I'd phrase it as: If you don't want to be forced to make a large effort managing memory for the given task, C is the wrong tool for that job. Even when you're great with C. Even when C is wonderful for a different job because you do it fabulously well. I use C and like it. I don't use it when python is good enough for the job because in those situations python is likely to be actually better than C because you'd incur a debt to pay for something you don't need and as a result you just might miss one of those payments. The interest rate on a missed payment can get pretty steep. Prefer shell, ruby, perl, something jvm, whatever? - Great. Exactly the same point applies. I'm sure this point does /not/ apply to your comment above but it could be (mis)interepreted that way - C programming macho arrogance is not helpful for good quality software. C macho arrogance is pretty destructive, in fact and IMHO the worst thing about the use C (& C++ etc.)
  - GuB-42 6y ago
    It was the intent of that line and I totally agree with your comment. C is definitely not the right tool for every job. And in fact, I don't write that much C for that reason, the cognitive load of tracking every bit of memory is high and not always justified. I wouldn't put C and "modern" C++ in the same class though. They are actually very different from a memory management perspective. You can write C++ like you write C, there are plenty of valid use cases for that. However, the "standard" way of doing C++ now implies things like containers, RAII and smart pointers. It means objects get allocated and de-allocated automatically, dangling pointers and buffer overflows are less likely, but it has a cost in terms of performance and control. Another tool for another job.
    - harry8 6y ago
      Yeah totally, completely agree. One of the things C and Modern idiomatic C++ (using C++11 on) have in common is some part of the culture surrounding them having a tolerance for, if not liking of, macho arrogance. "If you got burned it's purely because you're stupid and lazy which I am not, ha ha." This kind of vibe. Not everywhere by any means, but it exists and it's destructive to sensible analysis and the writing of good quality software, while alienating some talent from the pool of potential colleagues. I strongly dislike it.
- throw_m239339 6y ago
  > If you don't manage your memory precisely, then sure, C is probably not the language for you. > More like writing C properly. A lot of C problems could have been solved within the language without adding any kind of advanced CompSci construct. C is fundamentally outdated as a language and rely on assumptions and restrictions from the 70s. Unfortunately each time someone wants to replace C, they stuff the remplacements with the unnecessary evolved constructs I talked about. A language shouldn't need to be "written properly". Manual memory management doesn't have to be hard at first place, it is made hard by C weakly typed nature and horrid syntax.
  - bcrl 6y ago
    My personal feeling is that the compiler writers have gone overboard in their literal interpretation of "undefined behaviour". C on any real world machine has quite well defined (and expected) behaviour. In the real world we don't expect to have to support 6 bit or 18 bit CPUs today. Numbers are stored in binary, not trinary. The C spec should really be tightened up to define a lot of what was left undefined for these relics of history. The worst example of undefined behaviour abuse by a compiler is when gcc developers decided it was a good idea to optimize away a NULL pointer check just because the pointer was dereferenced. Seriously? Sometimes I really wonder who comes up with the idea that removing code the developer wrote is OK, but I guess that's the primary goal of any optimizing compiler.
- IshKebab 6y ago
  The point is that nobody does manage their memory "precisely". Everyone makes mistakes and in C those mistakes are fatal.