4 ms·

I'm a professional, C++ dev and my greatest quibble with C++ is its deranged system of numerical types, implicit conversions between them, and that signed arith

by zvrba 11y ago

I'm a professional, C++ dev and my greatest quibble with C++ is its deranged system of numerical types, implicit conversions between them, and that signed arithmetic can produce UB just about anytime: http://www.boost.org/doc/libs/1_55_0/libs/numeric/conversion/doc/html/boost_numericconversion/definitions.html http://www.boost.org/doc/libs/1_55_0/libs/numeric/conversion...

pjmlp 11y ago
Mostly inherited from C, actually.
- zvrba 11y ago
  Well, "defect by design" is still a defect and I have to work around it on almost daily basis. Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time. EDIT: actually, there are two defects here. One are the implicit numeric conversions. The other one, which causes me most grievance in this context, is that size() on containers returns an unsigned type.
  - helmut_hed 11y ago
    I'm curious about that last bit. I occasionally hear this argument that size_t being unsigned is a bad thing. Presumably the standard library designers would claim that a size cannot be negative, so this is appropriate. Why, in your view, should that be a signed quantity?
    - zvrba 11y ago
      Unsigned numbers in C++ are completely unsuitable for restricting the domain range because their "rank" (technical term) is higher than that of equally-sized signed types, which means that all operands are promoted to unsigned if one operand is unsigned. Of course, the result is unsigned too. Now, you often want to do arithmetic with numbers, right? You could think that, given two containers with c1.size() < c2.size(), that c1.size()-1 < c2.size()-1, right? Wrong. Because of default promotion rules and size() returning an unsigned number, (signed) 1 is converted to an unsigned number and the whole expression is evaluated in modulo arithmetic. Now, if c1 is empty (c1.size() == 0), then subtracting 1 from 0 in unsigned arithmetic wraps around (this is how unsigned arithmetic is defined) to a huge number (4 billion on 32 bit machines). The simple comparison above will fail in THE singular case of having an empty container on left hand side. You also lose any possibility of detecting errors. (E.g., if size() were signed and could return a negative number, you could effectively assert on that. If assert triggered, then something really bad happened -- maybe two concurrent threads modifying the data structure w/o proper synchronization.) I personally think it makes reasoning about a program harder; the above comparison was just the most trivial example. unsigned<>signed comparisons also trigger a bunch of warnings, because I use signed numbers for everything else, so the code ends up having a bunch of unnecessary casts. (I do not want to disable the warning because genuine mishaps of mixing signed/unsigned do happen.) I believe the consensus is (also Stroustrup's recommendation) is that unsigned should be used as "give me modulo arithmetic" instead of "this number cannot be negative". So, IMHO, unsigned size() was a mistake and is a big PITA when you try to develop robust software and creates less maintainable code (e.g. in the above simple example, you'd have to special-case the c1.empty() case with if). Casting size() to signed type immediately if I'm going to do anything else than iterate over the container is the least evil for me.
  - pjmlp 11y ago
    > Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time. Except that typedef int bool; /* or BOOL */ #define FALSE 0 #define TRUE (!(FALSE)) used to be quite common back then. So C++ only adopted an existing idiom in the C community.
    - zvrba 11y ago
      Is there any production-level C code which relies on (int+bool, and other semantically meaningless arithmetic) working? Besides, C++ broke nevertheless broke C compatibility because ++bool will never increment the value past 1, and bool=int will coerce int to 0 or 1. C will preserve the original values.
      - pjmlp 11y ago
        > Is there any production-level C code which relies on (int+bool, and other semantically meaningless arithmetic) working? Yes. I have seen enterprise code making interesting tricks to covert handle values into pointers, back in the late 90's.
        the_why_of_y 11y ago
        Code that switches over a variable nominally declared to be of type BOOL and handles more than 2 distinct value cases is always such a joy to read; every enterprise grade code base should have at least one of these for entertainment purposes.

by zvrba 11y ago

pjmlp 11y ago

Mostly inherited from C, actually.

zvrba 11y ago
Well, "defect by design" is still a defect and I have to work around it on almost daily basis. Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time. EDIT: actually, there are two defects here. One are the implicit numeric conversions. The other one, which causes me most grievance in this context, is that size() on containers returns an unsigned type.
- helmut_hed 11y ago
  I'm curious about that last bit. I occasionally hear this argument that size_t being unsigned is a bad thing. Presumably the standard library designers would claim that a size cannot be negative, so this is appropriate. Why, in your view, should that be a signed quantity?
  - zvrba 11y ago
    Unsigned numbers in C++ are completely unsuitable for restricting the domain range because their "rank" (technical term) is higher than that of equally-sized signed types, which means that all operands are promoted to unsigned if one operand is unsigned. Of course, the result is unsigned too. Now, you often want to do arithmetic with numbers, right? You could think that, given two containers with c1.size() < c2.size(), that c1.size()-1 < c2.size()-1, right? Wrong. Because of default promotion rules and size() returning an unsigned number, (signed) 1 is converted to an unsigned number and the whole expression is evaluated in modulo arithmetic. Now, if c1 is empty (c1.size() == 0), then subtracting 1 from 0 in unsigned arithmetic wraps around (this is how unsigned arithmetic is defined) to a huge number (4 billion on 32 bit machines). The simple comparison above will fail in THE singular case of having an empty container on left hand side. You also lose any possibility of detecting errors. (E.g., if size() were signed and could return a negative number, you could effectively assert on that. If assert triggered, then something really bad happened -- maybe two concurrent threads modifying the data structure w/o proper synchronization.) I personally think it makes reasoning about a program harder; the above comparison was just the most trivial example. unsigned<>signed comparisons also trigger a bunch of warnings, because I use signed numbers for everything else, so the code ends up having a bunch of unnecessary casts. (I do not want to disable the warning because genuine mishaps of mixing signed/unsigned do happen.) I believe the consensus is (also Stroustrup's recommendation) is that unsigned should be used as "give me modulo arithmetic" instead of "this number cannot be negative". So, IMHO, unsigned size() was a mistake and is a big PITA when you try to develop robust software and creates less maintainable code (e.g. in the above simple example, you'd have to special-case the c1.empty() case with if). Casting size() to signed type immediately if I'm going to do anything else than iterate over the container is the least evil for me.
- pjmlp 11y ago
  > Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time. Except that typedef int bool; /* or BOOL */ #define FALSE 0 #define TRUE (!(FALSE)) used to be quite common back then. So C++ only adopted an existing idiom in the C community.
  - zvrba 11y ago
    Is there any production-level C code which relies on (int+bool, and other semantically meaningless arithmetic) working? Besides, C++ broke nevertheless broke C compatibility because ++bool will never increment the value past 1, and bool=int will coerce int to 0 or 1. C will preserve the original values.
    - pjmlp 11y ago
      > Is there any production-level C code which relies on (int+bool, and other semantically meaningless arithmetic) working? Yes. I have seen enterprise code making interesting tricks to covert handle values into pointers, back in the late 90's.
      - the_why_of_y 11y ago
        Code that switches over a variable nominally declared to be of type BOOL and handles more than 2 distinct value cases is always such a joy to read; every enterprise grade code base should have at least one of these for entertainment purposes.