4 ms·
Have you worked with C++ much? It has the same problems to a much, much worse extent.
by wwright 6y ago
Have you worked with C++ much? It has the same problems to a much, much worse extent.
- skohan 6y agoI probably would not choose C++ either unless I really needed its USP's like extreme memory/performance optimization or required compatibility with exotic hardware. But at least with C++ you can compile a binary which won't behave differently on a different system most of the time. But there are a lot of other languages out there besides C++ and Python.
- fnord123 6y ago> 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 6y agoFair but I think my other points still stand
- KMag 6y agoThe 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 6y agoAny modern MS Windows desktop, that is, of course.
- fnord123 6y agoTbh 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 6y agoSure, then use Rust, with the added benefit of most of the linkage being static.
- wwright 6y agoOh, I agree. I was mostly saying this because my job uses C++ as the main language and boy oh boy is it the worst possible world.