5 ms·

Can't they add a new header file?

• flohofwoe 3y ago
  What if a library API needs to include this new header because it wants to use the new typedefs in its API declarations but your own code (which needs to include the library header) also has its own 'u8' typedefs? (PS: it's probably ok because C compilers seem to accept redundant typedefs)
  • sieabahlpark 3y ago
    It sounds like you got some refactoring to use since you didn't namespace your own core types?
    • flohofwoe 3y ago
      C doesn't have namespaces. The only sane way to deal with name collisions is either to use C stdlib types in library APIs (e.g. uint8_t), or use a library specific prefix (e.g. mylib_u8) - which is of course even more awkward than just using the standard uint8_t.
      • naasking 3y ago
        A prefix and a namespace aren't really that different in practice.
        • staunton 3y ago
          They are different. Namespaces are syntactically enforced and you can opt-in or out to names. To have syntactically validated qualified access. Naming might go well and have the same utility, but you never know what evil things are going on in all those headers, redefining each other's symbols and yours.
          • naasking 3y ago
            You seem to be focusing on specific problems with C/C++. I don't really care about that, all I'm saying is that prefixing names are equivalent to placing them within a namespace, in practice, and theoretically come to think of it. You can easily define a bijection between namespaced symbols and prefixed symbols. Requiring the full prefixes are simply a tad more verbose, essentially equivalent to using a fully qualified name for symbol.
      • sieabahlpark 3y ago
        [dead]
    • stephc_int13 3y ago
      I think that "namespacing" basic types such as u32 is completely unecessary. In what world would an u32_MYLIB would be different than an u32_SOMELIB? Basic types are common enough.
      • pavlov 3y ago
        The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.
        • pornel 3y ago
          If C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.
          • saagarjha 3y ago
            foo.h defines i64 as “long” and bar.h defines it as “long long”. Now what?
          • kevin_thibedeau 3y ago
            This would break legacy code. I had one employer with a bool type that was a 32-bit integer because of obscure alignment issues. This is why _Bool exists and the bool typedef has to be brought in explicitly with stdbool. You can't just go and usurp popular short type names. The standard reserved *_t and _[A-Z].+ for this purpose. People have been writing portable code with the expectation that future standards aren't going violate that promise and break things.
            • alexvoda 3y ago
              This is just one of the reasons that new languages that dispense with outdated assumptions and insted make assumptions more suitable to our times are a good thing. C and C++ are really old and some things can not be fixed with libraries.
  • pjmlp 3y ago
    Same reasoning applies to new keywords.