4 ms·

> But at least with C++ you can compile a binary which won't behave differently on a different system most of the time. Not really, no. Only if the compiler, c

> But at least with C++ you can compile a binary which won't behave differently on a different system most of the time. Not really, no. Only if the compiler, compiler version, compilation flags, kernel version, platform, platform version, cpu version, directory structure, shared object versions, locale, environment (LD_PRELOAD, LD_LIBRARY_PATH, TZ), config in pwd, .local, and /etc or maybe $XDG_*, "~/Library/Application Support/" are all the same.

skohan 7y ago
Fair but I think my other points still stand
KMag 7y ago
The GP specifically was talking about the binary behaving differently, so the compiler version and compilation flags would be irrelevant. The kernel, system libraries, environment variables, etc. would all still be relevant, though. I think they're referring to unpredictable behavior under future versions of language VMs and garbage collectors vs. statically compiled binaries with either no GC or a statically linked GC library. Most of the time, all of that machinery going on behind the scenes is very convenient, but coding strictly to POSIX and the C/C++ standard libraries / STL and keeping your compilation artifacts gives you a lot more stability than coding to some version of the Java standard library (or other language VM) and keeping around your JVM installer with hopes that the installer will agree to install and run on future systems. I remember being bitten by testing our product against the earliest JRE we supported and also the latest JRE sun had released at the time. I was aware that reading environment variables was deprecated in the earliest JRE I tested with, and I knew it had been un-deprecated in the latest JRE I tested, and the methods I was using were present in all of the JRE versions in between. What I had missed was that there was at least one JRE version in the middle where the deprecated environment variable reading methods actually threw runtime errors. I've also run into issues in the past with the version of MSVC I was required to use having an installer that depended upon some ancient version of the CLR which would no longer install on my machine. There were some workarounds, but I needed to talk to several of our helpdesk people before I found someone who knew the required magic incantations. Had the MSVC installer been coded strictly to C++ stdlib, STL, Win32 and MFC, it would have run just fine on my modern desktop.
- KMag 7y ago
  Any modern MS Windows desktop, that is, of course.
- fnord123 7y ago
  Tbh Ive debugged too many multithreaded c++ programs with memory leaks, corrupt stacks, corrupt heaps, double frees, string algorithms flying off the end of a buffer, etc to take the idea that a C++ program running twice in a row will do the same thing.
  - KMag 7y ago
    Sure, then use Rust, with the added benefit of most of the linkage being static.

skohan 7y ago

Fair but I think my other points still stand

KMag 7y ago

The GP specifically was talking about the binary behaving differently, so the compiler version and compilation flags would be irrelevant. The kernel, system libraries, environment variables, etc. would all still be relevant, though. I think they're referring to unpredictable behavior under future versions of language VMs and garbage collectors vs. statically compiled binaries with either no GC or a statically linked GC library. Most of the time, all of that machinery going on behind the scenes is very convenient, but coding strictly to POSIX and the C/C++ standard libraries / STL and keeping your compilation artifacts gives you a lot more stability than coding to some version of the Java standard library (or other language VM) and keeping around your JVM installer with hopes that the installer will agree to install and run on future systems. I remember being bitten by testing our product against the earliest JRE we supported and also the latest JRE sun had released at the time. I was aware that reading environment variables was deprecated in the earliest JRE I tested with, and I knew it had been un-deprecated in the latest JRE I tested, and the methods I was using were present in all of the JRE versions in between. What I had missed was that there was at least one JRE version in the middle where the deprecated environment variable reading methods actually threw runtime errors. I've also run into issues in the past with the version of MSVC I was required to use having an installer that depended upon some ancient version of the CLR which would no longer install on my machine. There were some workarounds, but I needed to talk to several of our helpdesk people before I found someone who knew the required magic incantations. Had the MSVC installer been coded strictly to C++ stdlib, STL, Win32 and MFC, it would have run just fine on my modern desktop.

KMag 7y ago
Any modern MS Windows desktop, that is, of course.
fnord123 7y ago
Tbh Ive debugged too many multithreaded c++ programs with memory leaks, corrupt stacks, corrupt heaps, double frees, string algorithms flying off the end of a buffer, etc to take the idea that a C++ program running twice in a row will do the same thing.
- KMag 7y ago
  Sure, then use Rust, with the added benefit of most of the linkage being static.