At this point, there is no reason not to.
Why does the solution need to work for C?
But even if you do that, you still need to fix the existing min()/max() ... macros.
this kind of stuff really should be done by the compiler and LibC people
"The ISO C90 functions abs, cos, exp, fabs, fprintf, fputs, labs, log, memcmp, memcpy, memset, printf, putchar, puts, scanf, sin, snprintf, sprintf, sqrt, sscanf, strcat, strchr, strcmp, strcpy, strcspn, strlen, strncat, strncmp, strncpy, strpbrk, strrchr, strspn, strstr, vprintf and vsprintf are all recognized as built-in functions unless -fno-builtin is specified (or -fno-builtin-function is specified for an individual function). All of these functions have corresponding versions prefixed with __builtin_."
Simple solution would be to wrap the old-school stuff in the #else of #ifdef __cplusplus. That way, the modern folks can have a well-behaved compiler-driven solution, and people who for some reason like C *and* Arduino, can have something that works.
A problem with implementing them as a function is STACK USAGE - Will they use more stack space (only 2K RAM, remember?) as a function or as a macro?
Stack is much more limited than is program memory. While it might be good to optimize for FLASH usage, you must not forget limited RAM.
The biggest drawback of these macros is the inability to use those macro names in your own code. A range class for example would benefit from members named min & max over something like LowVal and HighVal for example.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16