6 ms·

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

ncmncm 6y ago
Agree. And they have leaked out to C++ where they have been very hard to fix, and even, to some degree, to Rust.
- forrestthewoods 6y ago
  How have they leaked into Rust? I thought Rust had no implicit conversions?
  - steveklabnik 6y ago
    There are a small number of coercions, but we do not do them around numeric types, it’s true. Not sure what your parent is referring to.
  - ncmncm 6y ago
    It does, however, have integer overflow, in release mode. So if you do code a conversion, you can end up with a value different from the source.
    - carlmr 6y ago
      But that's because Rust designs for zero cost abstractions in release mode. Overflow checking is not zero cost, so it's only enabled in debug mode, which is the maximum safety possible here while keeping it zero cost at (release) runtime. Without dependent types or something similar I don't know if it would be possible to check bounds.
      - ncmncm 6y ago
        Yes, there are reasons for it.
rowanG077 6y ago
I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.
- colejohnson66 6y ago
  Why should I need to use a flag to fix something that doesn’t make sense? I can understand implicit up-conversions, but down-conversions too?
  - leetcrew 6y ago
    you can certainly argue it should have been a default warning from the beginning, but mistakes were made and it's a bit too late to change that. people don't like when old, battle-tested code suddenly starts spewing a new warning everywhere after a compiler update. in reality, most production build systems at least use -Wall (or their compiler's equivalent) and possibly also have a list of specific warnings turned on/off for different parts of the code. it would be nice to have some saner defaults, but it just doesn't matter that much.
  - rowanG077 6y ago
    I'm not arguing that the original design was good or bad. I'm simply saying that it's as simple as adding a flag to the compiler these days.
leetcrew 6y ago
on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almost always be a bug, since they are in different spaces. would be cool to get this functionality out of the humble typedef.
- syrrim 6y ago
  structs
- Reelin 6y ago
  This has always bugged me as well. I've generally solved this by wrapping things in a struct. Type checking will use the (incompatible) wrappers and a modern compiler should optimize them away. To avoid strict aliasing violations when converting between equivalent wrapped types you can use a union and employ a function to hide the verbosity. I have no idea if this is the "right" way to do things, but it seems to work.
  - alternatetwo 6y ago
    That's what Microsoft did from some version on in their build tools, all the HANDLE's etc used to just be typedef void , now they're a dummy struct each (HANDLE__ ). Seems to be a good solution.
    - pjmlp 6y ago
      That was already opt-in back in the Windows 3.1 days, but few bothered to use it as such. Back when I was doing pure Windows C for a while, this helped quite a bit, Basically you had to #include<windowsx.h> and define the STRICT macro. There were also several utilities that made it much easier to deal with events, dialogs and callbacks. https://docs.microsoft.com/en-us/windows/win32/api/windowsx/ https://docs.microsoft.com/en-us/windows/win32/api/windowsx/ https://jeffpar.github.io/kbarchive/kb/083/Q83456/ https://jeffpar.github.io/kbarchive/kb/083/Q83456/ I got to learn it via the "Programmer's introduction to Windows 3.1" book, https://archive.org/details/programmersintro00myer https://archive.org/details/programmersintro00myer
moonchild 6y ago
The exact-width integer types proposal[1], implemented in clang, happens to fix this. 1. http://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html http://blog.llvm.org/2020/04/the-new-clang-extint-feature-pr...

ncmncm 6y ago

Agree. And they have leaked out to C++ where they have been very hard to fix, and even, to some degree, to Rust.

forrestthewoods 6y ago
How have they leaked into Rust? I thought Rust had no implicit conversions?
- steveklabnik 6y ago
  There are a small number of coercions, but we do not do them around numeric types, it’s true. Not sure what your parent is referring to.
- ncmncm 6y ago
  It does, however, have integer overflow, in release mode. So if you do code a conversion, you can end up with a value different from the source.
  - carlmr 6y ago
    But that's because Rust designs for zero cost abstractions in release mode. Overflow checking is not zero cost, so it's only enabled in debug mode, which is the maximum safety possible here while keeping it zero cost at (release) runtime. Without dependent types or something similar I don't know if it would be possible to check bounds.
    - ncmncm 6y ago
      Yes, there are reasons for it.

rowanG077 6y ago

I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.

colejohnson66 6y ago
Why should I need to use a flag to fix something that doesn’t make sense? I can understand implicit up-conversions, but down-conversions too?
- leetcrew 6y ago
  you can certainly argue it should have been a default warning from the beginning, but mistakes were made and it's a bit too late to change that. people don't like when old, battle-tested code suddenly starts spewing a new warning everywhere after a compiler update. in reality, most production build systems at least use -Wall (or their compiler's equivalent) and possibly also have a list of specific warnings turned on/off for different parts of the code. it would be nice to have some saner defaults, but it just doesn't matter that much.
- rowanG077 6y ago
  I'm not arguing that the original design was good or bad. I'm simply saying that it's as simple as adding a flag to the compiler these days.

leetcrew 6y ago

on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almost always be a bug, since they are in different spaces. would be cool to get this functionality out of the humble typedef.

syrrim 6y ago
structs
Reelin 6y ago
This has always bugged me as well. I've generally solved this by wrapping things in a struct. Type checking will use the (incompatible) wrappers and a modern compiler should optimize them away. To avoid strict aliasing violations when converting between equivalent wrapped types you can use a union and employ a function to hide the verbosity. I have no idea if this is the "right" way to do things, but it seems to work.
- alternatetwo 6y ago
  That's what Microsoft did from some version on in their build tools, all the HANDLE's etc used to just be typedef void , now they're a dummy struct each (HANDLE__ ). Seems to be a good solution.
  - pjmlp 6y ago
    That was already opt-in back in the Windows 3.1 days, but few bothered to use it as such. Back when I was doing pure Windows C for a while, this helped quite a bit, Basically you had to #include<windowsx.h> and define the STRICT macro. There were also several utilities that made it much easier to deal with events, dialogs and callbacks. https://docs.microsoft.com/en-us/windows/win32/api/windowsx/ https://docs.microsoft.com/en-us/windows/win32/api/windowsx/ https://jeffpar.github.io/kbarchive/kb/083/Q83456/ https://jeffpar.github.io/kbarchive/kb/083/Q83456/ I got to learn it via the "Programmer's introduction to Windows 3.1" book, https://archive.org/details/programmersintro00myer https://archive.org/details/programmersintro00myer

moonchild 6y ago

The exact-width integer types proposal[1], implemented in clang, happens to fix this. 1. http://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html http://blog.llvm.org/2020/04/the-new-clang-extint-feature-pr...