3 ms·

I think one major point is the unreadable mess, though. Is there a reason for this?

by buster 6y ago

rightbyte 6y ago
Any big standard lib I laid my eyes on (gcc, clang, MS headers) seems to be a mess. I too wonder if the complexity is really necessary, but I guess so? Macros in my experience is ofent to fool the compiler to generate better code. Maybe that is a legacy reason?
- ThreeFx 6y ago
  99% of the time the answer is speed. It's just way faster to evaluate and build all of this at compile time than at runtime. I understand both sides of the argument here - on one hand you have fast and unreadable code and on the other hand slower and more readable code. The problem here is 1. the leaky abstraction of characters and code points and 2. loss of type safety due to C's weak typing rules, which is a bit lost in the "hurr durr messy code."
- DaiPlusPlus 6y ago
  Windows.h is still full of obsolete ancient macros that can’t be removed for compatibility. Things like references to near and far pointers (still!) and how every Win32 function with string params is a macro for the real A/W-suffixed functions, and all the A-suffixed functions now intentionally crash on post-98 systems.
  - tjalfi 6y ago
    > all the A-suffixed functions now intentionally crash on post-98 systems. Do you have a source for this claim? I find it hard to believe that Microsoft would drop support for ANSI applications.
johannes1234321 6y ago
There are a number of reasons: - Support for weird compilers - Focus on performance, thus playing "weird" tricks with macros, lookup tables etc. - especially in headers: protect against users doing crazy sh*t - standards sometimes change or see extensions - certainly more :) First two items can be re-evaluated form time to time, but especially GNU often aims to run "anywhere" The third item comes from the fact that users can create macros for many things and only some names (leading _ and capital letter or __) are reserved for standards or C++ allowing to overload the comma operator, which can have weird effects. Thus to be conformant to the standards some ugliness is required. The fourth point combined with different compatibility requirements requires tricks to switch between different implementations based on compiler flags/macros (for instance `#define _GNU_SOURCE` or `#define _POSIX_C_SOURCE=...`)

I think one major point is the unreadable mess, though. Is there a reason for this?

by buster 6y ago

I think one major point is the unreadable mess, though. Is there a reason for this?

Any big standard lib I laid my eyes on (gcc, clang, MS headers) seems to be a mess. I too wonder if the complexity is really necessary, but I guess so? Macros in my experience is ofent to fool the compiler to generate better code. Maybe that is a legacy reason?

ThreeFx 6y ago
99% of the time the answer is speed. It's just way faster to evaluate and build all of this at compile time than at runtime. I understand both sides of the argument here - on one hand you have fast and unreadable code and on the other hand slower and more readable code. The problem here is 1. the leaky abstraction of characters and code points and 2. loss of type safety due to C's weak typing rules, which is a bit lost in the "hurr durr messy code."
DaiPlusPlus 6y ago
Windows.h is still full of obsolete ancient macros that can’t be removed for compatibility. Things like references to near and far pointers (still!) and how every Win32 function with string params is a macro for the real A/W-suffixed functions, and all the A-suffixed functions now intentionally crash on post-98 systems.
- tjalfi 6y ago
  > all the A-suffixed functions now intentionally crash on post-98 systems. Do you have a source for this claim? I find it hard to believe that Microsoft would drop support for ANSI applications.

johannes1234321 6y ago

There are a number of reasons: - Support for weird compilers - Focus on performance, thus playing "weird" tricks with macros, lookup tables etc. - especially in headers: protect against users doing crazy sh*t - standards sometimes change or see extensions - certainly more :) First two items can be re-evaluated form time to time, but especially GNU often aims to run "anywhere" The third item comes from the fact that users can create macros for many things and only some names (leading _ and capital letter or __) are reserved for standards or C++ allowing to overload the comma operator, which can have weird effects. Thus to be conformant to the standards some ugliness is required. The fourth point combined with different compatibility requirements requires tricks to switch between different implementations based on compiler flags/macros (for instance `#define _GNU_SOURCE` or `#define _POSIX_C_SOURCE=...`)