2 ms·

I decided to be pedantic and check. 1 - Language agnostic 2 - Agnostic - Java doesn't have memcmp but the same issue returning (-1, or < 0) could happen 3 -

I decided to be pedantic and check. 1 - Language agnostic 2 - Agnostic - Java doesn't have memcmp but the same issue returning (-1, or < 0) could happen 3 - Agnostic (with the exception that java would throw for out of bounds) 4 - Agnostic 5 - Agnostic - Its a windows complication (you can write C++ without DllMain even in windows) 6 - C++ 7 - C++ 8 - C++ 9 - C++ 10 - C++ 11 - C++ 12 - Agnostic 13 - Agnostic 14 - Agnostic 15 - C++ 16 - Agnostic 17 - Agnostic (java has similar optimizations) 18 - Agnostic (inefficient code happens in any language) 19 - C++ 20 - C++ (maybe java would throw instead?) ... This is longer than I thought. 9 of the first 20 are C++ only.

wuch 10y ago
2. Language agnostic; Common in other languages, but some avoid it by using strongly typed enumeration instead of integer return type in comparison functions. 6. Languages with pointer arithmetic, especially that the cast that losses information is explicit. 8. It not at all obvious that silently ignoring the case failure is correct fix for this, or if there is any issue here at all. Generally common to languages with some kind of destructor and exceptions, though harmful in varying degrees. 11. Other languages generally make it impossible to write, or define order of operations. I think the most interesting observation you can make is how much of those problems are caused by some form of implicit conversion between types (also stopped after 20): 4. int -> bool 9. char -> *char 13. int -> bool 14. bool -> size_t 15. different enums 16. bool -> int This generally agrees with bug log that I keep. Implicit conversions being one of the most common source of problems in C/C++. When possible I just treat all implicit conversions as errors using compiler flags and make all casts explicit. Unfortunately this is something you can only do when working on new projects, and hard to enforce in templates.

wuch 10y ago

2. Language agnostic; Common in other languages, but some avoid it by using strongly typed enumeration instead of integer return type in comparison functions. 6. Languages with pointer arithmetic, especially that the cast that losses information is explicit. 8. It not at all obvious that silently ignoring the case failure is correct fix for this, or if there is any issue here at all. Generally common to languages with some kind of destructor and exceptions, though harmful in varying degrees. 11. Other languages generally make it impossible to write, or define order of operations. I think the most interesting observation you can make is how much of those problems are caused by some form of implicit conversion between types (also stopped after 20): 4. int -> bool 9. char -> *char 13. int -> bool 14. bool -> size_t 15. different enums 16. bool -> int This generally agrees with bug log that I keep. Implicit conversions being one of the most common source of problems in C/C++. When possible I just treat all implicit conversions as errors using compiler flags and make all casts explicit. Unfortunately this is something you can only do when working on new projects, and hard to enforce in templates.