3 ms·

>1 I'm conflicted about this one. I choose not to try and emulate generics with macros because adding language features with macros is a terrible idea. On the

>1 I'm conflicted about this one. I choose not to try and emulate generics with macros because adding language features with macros is a terrible idea. On the other hand, I recognize the problem with void*. It's a matter for debate but I definitely fall on the "don't use macros for this" side. >2 This is a case where I would rather write more code than rely on magic. You have to have this awful hacky opaque implementation in exchange for a trivial improvement in ergonimics. No thanks. >3 I mean, just look at this code. Or better yet, have someone else look at it. This is totally unreadable and unmaintainable, all for a marginal ergnomics improvement. >4 Just use strtol or strtof. Do you really run into this that often? All of these are demonstrating exactly the problem I have with a lot of C authors. You build these esoteric systems that use heaps of unmaintainable, unreadable code to provide marginal gains elsewhere.

makapuf 10y ago
#define IT "I think" // :) >2 IT the swicth/cases are quicker/clearer to grasp than the one with BIGMACROS_X >4 IT you shouldn't underestimate the existing neural paths of knowledge of stdlib for C devs. those std functions are read / parsed almost intuitively, unlike cute macros, except for their creator. I'am ll for "cleaning" C and have a non-completely backwards dependent / improved standard, but I'd much prefer strtof than a custom macro. And those standard C functions are often accelerated to death by compilers (see: memcpy by example).
cperciva 10y ago
Just use strtol or strtof Which of these is more likely to have bugs? int i; if (PARSENUM(&i, s, 0, 1000)) err("Invalid input: %s", s); or int i; long l; // need a temporary long to avoid overflow char * ep; errno = 0; l = strtol(s, &ep, 0); if ((ep == s) || (*ep = '\0')) // make sure we parsed a number and don't have trailing garbage errno = EINVAL; if ((l < 0) || (l > 1000)) errno = ERANGE; if (errno) err("Invalid input: %s", s); i = l; You build these esoteric systems that use heaps of unmaintainable, unreadable code Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain.
- Sir_Cmpwn 10y ago
  To be honest I would just have your library offer a function that does it your fancy way. I agree that there could be better integer parsing functions, I disagree that they should be macros. >Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. Not worth it.
  - cperciva 10y ago
    To be honest I would just have your library offer a function that does it your fancy way. It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. All of my macros are intelligible to anyone who understands the C preprocessor. More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library?
    - Sir_Cmpwn 10y ago
      >It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Just tack an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. And you don't have to hold shift the whole time. >All of my macros are intelligible to anyone who understands the C preprocessor. I understand the C preprocessor fine and I have to stop and mentally decode all the crap your macros are trying to do. >More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library? All code is liable to have bugs. All code is liable to have performance issues. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc?
rimliu 10y ago
So others' argument is: I have macro I don't have to read code at all Your argument is: macros a bad, so have explicit code everywhere. This of course makes it to be readable a must. For me clearly named macro beats the need to parse few lines of code even if they are very clear and readable.

makapuf 10y ago

#define IT "I think" // :) >2 IT the swicth/cases are quicker/clearer to grasp than the one with BIGMACROS_X >4 IT you shouldn't underestimate the existing neural paths of knowledge of stdlib for C devs. those std functions are read / parsed almost intuitively, unlike cute macros, except for their creator. I'am ll for "cleaning" C and have a non-completely backwards dependent / improved standard, but I'd much prefer strtof than a custom macro. And those standard C functions are often accelerated to death by compilers (see: memcpy by example).

cperciva 10y ago

Just use strtol or strtof Which of these is more likely to have bugs? int i; if (PARSENUM(&i, s, 0, 1000)) err("Invalid input: %s", s); or int i; long l; // need a temporary long to avoid overflow char * ep; errno = 0; l = strtol(s, &ep, 0); if ((ep == s) || (*ep = '\0')) // make sure we parsed a number and don't have trailing garbage errno = EINVAL; if ((l < 0) || (l > 1000)) errno = ERANGE; if (errno) err("Invalid input: %s", s); i = l; You build these esoteric systems that use heaps of unmaintainable, unreadable code Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain.

Sir_Cmpwn 10y ago
To be honest I would just have your library offer a function that does it your fancy way. I agree that there could be better integer parsing functions, I disagree that they should be macros. >Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. Not worth it.
- cperciva 10y ago
  To be honest I would just have your library offer a function that does it your fancy way. It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. All of my macros are intelligible to anyone who understands the C preprocessor. More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library?
  - Sir_Cmpwn 10y ago
    >It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Just tack an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. And you don't have to hold shift the whole time. >All of my macros are intelligible to anyone who understands the C preprocessor. I understand the C preprocessor fine and I have to stop and mentally decode all the crap your macros are trying to do. >More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library? All code is liable to have bugs. All code is liable to have performance issues. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc?

rimliu 10y ago

So others' argument is: I have macro I don't have to read code at all Your argument is: macros a bad, so have explicit code everywhere. This of course makes it to be readable a must. For me clearly named macro beats the need to parse few lines of code even if they are very clear and readable.