5 ms·

Using compiler built-ins makes one’s code instantly unportable and is therefore unacceptable.

jchw 8y ago
When it comes to anything that isn't embedded work, I only care about platforms that support GCC or Clang. I'd happily take an improvement to my development workflow at the cost of dropping support for fringe users. Making truly portable C or C++ code is an exercise in utter pointlessness, and is usually impractical for non-trivial software, be it a desktop application, an operating system kernel, and a lot of things in between. By marketshare an extreme majority of computers and phones in the world can be targeted with Clang alone. Giving up useful compiler extensions to gain compatibility for a platform used by 0.0001% of computer users seems very pointless. I'd rather be concerned with making my software accessible to those with visual impairments or other disabilities, a way, way huger demographic, one that you can't choose to not be a part of.
- Annatar 8y ago
  Well we disagree vehemently: writing clean C code that compiles with any ANSI C compiler is pretty damn easy. Take BIND for example, a non-trivial piece of software which compiles with any compiler.
hossbeast 8y ago
Not at all. You wrap it in an ifdef macro by platform.
- Annatar 8y ago
  That’s a solution of last resort, when all else has failed, an act of desperation: whosoever does that is saying: “I don’t know how to express this in a generic fashion”, or “it’s too much work to do it that way and I don’t want to deal with it”. Since the very reason we get paid as programmers is to deal with it, I argue that such an act constitutes a breach of grounds on which we are being paid.
  - Mikhail_Edoshin 8y ago
    By generically you mean "in C"? Sometimes the functionality is there, but there's no way to express it in C. Integer overflows are exactly such a case; many processors provide a built-in overflow detection mechanism, but there's no way to access it in C. (It's not even a special mechanism, it's just the command itself, in assembly you clearly see the overflow.) I'd say that using compiler-specific functions (provided they plug into these processor commands) or assembly is exactly the right way to deal with this issue. Yes, parts of the code will be non-portable, but if they're clearly isolated and marked as machine-specific, then why not? The pros certainly outweigh the cons.
    - Annatar 8y ago
      I had exactly that happen when compiling PowerDNS: the developers relied on a GCC intrinsic, so I had to embark on an epic journey of building and packaging a newer version of GCC. Just to be able to serve DNS answers. That’s just so wrong.
exDM69 8y ago
On the contrary, compiler built-ins can make your code more portable (across different hw architectures) at the expense of some other compilers. GCC and Clang have mostly compatible compiler intrinsics and with those two compilers you can compile your software to almost any platform out there. If you need to get your code compiled on MSVC or ICC or some niche C compiler, you can work around this by adding some kind of wrapper around them with #ifdefs (not pretty). With compiler built-ins you get SIMD, atomics, bitops (popcnt, clz, etc) that are portable to almost any CPU instruction set out there. Without them, you have to re-write that code for every instruction set you intend to support. So your options are: 1) Stick to standard C and write code that compiles to suboptimal output code (such as using division to get multiply-with-overflow) 2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers 3) Write wrappers around compiler built-ins with #ifdefs to support all the compilers you want (add fallback to standard C if you need to) 4) Write your code using HW-specific intrinsics or inline assembly Out of these, option 2) will give you maximum portability with least amount of effort. The other options are more effort and the benefits are arguable. If you think there are other viable options, please do share.
- BeeOnRope 8y ago
  A variant of (3) that seems close to ideal is to use conditionally defined functions as suggested, that someone else has already written and generously shared, such as portable-snippets [0]. It has a component specifically to offer cross platform builtins with fallback/emulation on plaforms without direct support. [0] https://github.com/nemequ/portable-snippets https://github.com/nemequ/portable-snippets
  - exDM69 8y ago
    Thanks for the link, that looks quite useful if compiler portability is needed. It's still more effort than option #2, but quite an acceptable trade-off.
- Annatar 8y ago
  “2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers” Writing code to two specific compilers (clang and gcc) is NOT portable code. This is absolutely unacceptable behavior.

jchw 8y ago

When it comes to anything that isn't embedded work, I only care about platforms that support GCC or Clang. I'd happily take an improvement to my development workflow at the cost of dropping support for fringe users. Making truly portable C or C++ code is an exercise in utter pointlessness, and is usually impractical for non-trivial software, be it a desktop application, an operating system kernel, and a lot of things in between. By marketshare an extreme majority of computers and phones in the world can be targeted with Clang alone. Giving up useful compiler extensions to gain compatibility for a platform used by 0.0001% of computer users seems very pointless. I'd rather be concerned with making my software accessible to those with visual impairments or other disabilities, a way, way huger demographic, one that you can't choose to not be a part of.

Annatar 8y ago
Well we disagree vehemently: writing clean C code that compiles with any ANSI C compiler is pretty damn easy. Take BIND for example, a non-trivial piece of software which compiles with any compiler.

hossbeast 8y ago

Not at all. You wrap it in an ifdef macro by platform.

Annatar 8y ago
That’s a solution of last resort, when all else has failed, an act of desperation: whosoever does that is saying: “I don’t know how to express this in a generic fashion”, or “it’s too much work to do it that way and I don’t want to deal with it”. Since the very reason we get paid as programmers is to deal with it, I argue that such an act constitutes a breach of grounds on which we are being paid.
- Mikhail_Edoshin 8y ago
  By generically you mean "in C"? Sometimes the functionality is there, but there's no way to express it in C. Integer overflows are exactly such a case; many processors provide a built-in overflow detection mechanism, but there's no way to access it in C. (It's not even a special mechanism, it's just the command itself, in assembly you clearly see the overflow.) I'd say that using compiler-specific functions (provided they plug into these processor commands) or assembly is exactly the right way to deal with this issue. Yes, parts of the code will be non-portable, but if they're clearly isolated and marked as machine-specific, then why not? The pros certainly outweigh the cons.
  - Annatar 8y ago
    I had exactly that happen when compiling PowerDNS: the developers relied on a GCC intrinsic, so I had to embark on an epic journey of building and packaging a newer version of GCC. Just to be able to serve DNS answers. That’s just so wrong.

exDM69 8y ago

On the contrary, compiler built-ins can make your code more portable (across different hw architectures) at the expense of some other compilers. GCC and Clang have mostly compatible compiler intrinsics and with those two compilers you can compile your software to almost any platform out there. If you need to get your code compiled on MSVC or ICC or some niche C compiler, you can work around this by adding some kind of wrapper around them with #ifdefs (not pretty). With compiler built-ins you get SIMD, atomics, bitops (popcnt, clz, etc) that are portable to almost any CPU instruction set out there. Without them, you have to re-write that code for every instruction set you intend to support. So your options are: 1) Stick to standard C and write code that compiles to suboptimal output code (such as using division to get multiply-with-overflow) 2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers 3) Write wrappers around compiler built-ins with #ifdefs to support all the compilers you want (add fallback to standard C if you need to) 4) Write your code using HW-specific intrinsics or inline assembly Out of these, option 2) will give you maximum portability with least amount of effort. The other options are more effort and the benefits are arguable. If you think there are other viable options, please do share.

BeeOnRope 8y ago
A variant of (3) that seems close to ideal is to use conditionally defined functions as suggested, that someone else has already written and generously shared, such as portable-snippets [0]. It has a component specifically to offer cross platform builtins with fallback/emulation on plaforms without direct support. [0] https://github.com/nemequ/portable-snippets https://github.com/nemequ/portable-snippets
- exDM69 8y ago
  Thanks for the link, that looks quite useful if compiler portability is needed. It's still more effort than option #2, but quite an acceptable trade-off.
Annatar 8y ago
“2) Use compiler built-ins and get portability across different HW at the expense of not supporting other compilers” Writing code to two specific compilers (clang and gcc) is NOT portable code. This is absolutely unacceptable behavior.