6 ms·

> Multiplatform code when tested tends to show more bugs than single platform code. Why would it make the code more robust for users on other platforms if they

by davesmith1983 7y ago

> Multiplatform code when tested tends to show more bugs than single platform code. Why would it make the code more robust for users on other platforms if they aren't experiencing those bugs? Is exposing these bugs worth the extra development time? Surely just compiling with a different compiler is as likely to find bug in the compiler. I am not saying you are wrong but you are making a lot of assumptions.

berkut 7y ago
This has been my experience as well writing cross-platform software (some of it proprietary in the past). Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example. Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway). Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there. Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).
- davesmith1983 7y ago
  I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?
  - berkut 7y ago
    It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently). A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.
    - davesmith1983 7y ago
      Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0. If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects. The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.
- Thetawaves 7y ago
  Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.

berkut 7y ago

This has been my experience as well writing cross-platform software (some of it proprietary in the past). Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example. Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway). Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there. Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).

davesmith1983 7y ago
I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?
- berkut 7y ago
  It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently). A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.
  - davesmith1983 7y ago
    Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0. If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects. The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.
Thetawaves 7y ago
Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.