3 ms·
This isn’t my experience of running old VC++ projects. They usually end up with some weird linker errors because they embed a hardcoded DLL or something which w
by josephg 4y ago
This isn’t my experience of running old VC++ projects. They usually end up with some weird linker errors because they embed a hardcoded DLL or something which was compiled with an old version of visual studio or something. You get a lot better at fixing these errors with experience, but I’ve lost count of the number of hours I’ve lost noodling with this stuff to compile some old code.
Speaking of progress, I adore this improvement in modern languages. C#, Swift, Rust and nodejs all have officially defined project configuration alongside the source code. I expect to be able to “cargo run” any of my rust programs in 50 years from now just as easily as I can today.
- HexDecOctBin 4y ago50 years from now, "Swift, Rust and nodejs" might not exist. For that sort of time period, you either need a language whose compiler & runtime is easy to write (C, Forth, Scheme, etc.) or a language that compiles to standardised bytecode (C#, Java, etc.).
- josephg 4y agoWhy wouldn’t they exist?
- HexDecOctBin 4y agoBecause things die.
- jiggawatts 4y agoThat's not an issue with "Visual Studio as an IDE", but "Microsoft's C++ build toolchain" combined with specific issues with C++ the language itself, such as: not having a stable ABI, no truly common stdlib, no package manager, and weird linker conflicts due to the way headers interact with static values. This is the primary reason I've abandoned C++ programming in general, and I'm never going back. From what I can see, the alternative C++ toolchains from other vendors (and open source) aren't fundamentally better. They might paper over one or two issues, but rarely solve the core problem in a permanent way. These days I do only C# and Rust for the same reason you mentioned -- sane project, dependency, and build management.
- chaosite 4y agoBut the whole argument is toolchain integrated with an IDE (the I, remember?)
- jiggawatts 4y agoC++ toolchains in general are broken with or without IDEs. It doesn't matter if you're compiling from the command-line or a GUI, it's a trash fire either way. This problem is sometimes temporarily "fixed" by some approach, but the problem is fundamentally with C++ itself, making many basic things night impossible to solve. Eventually the new "simple" toolchain is adapted to support every possible scenario, and then madness creeps back in and we're back to square one. For example, I recently had to compile Chromium from scratch. It has a custom build system (of course), that is more complex by itself than all of the code that I have written in my entire life put together. It was written to "simplify" its builds. That's... crazy. I vividly remember the day I snapped and gave up C++. I was trying to compile previously working code and it was complaining that "__malloc" was undefined. This was a linker error with no further information. It didn't identify the source of the problem, and provided no clue on how to fix it. After hours of effort I simply gave up, switched over to C#, and never looked back. PS: A part of the reason C/C++ developers don't "get" why IDEs are so popular is precisely because C and C++ are so hard to write IDEs for! A single header file can mean different things in the same project depending on where and how it is included. Simply providing tab-complete and inline help is a monumental task. So most C++ IDEs are bare bones compared to Java or C#. They do basically nothing for the developer except the basics. PPS: The Rust team are all ex-C++ programmers and made the same mistakes in their language design, making IDEs very challenging to write for Rust. Don't agree? Remind me, how many IDEs are available that can do something as trivial as "extract method" in Rust?
- josephg 4y ago> Remind me, how many IDEs are available that can do something as trivial as "extract method" in Rust? Intellij can. I use it all the time. I’m not sure about rust-analyzer with vs code.