If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.
Ah, binary-only dependencies, right… That's very specific though, so unless you need to drive some proprietary hardware, why bother using stuff that forces you into MSVC hell lol? Also wouldn't LLVM based MinGW benefit from Clang's MSVC compat? Not sure about this at all, that's why I'm asking, heh… ^^"
Wait till they find out what the Visual Studio Installer itself does :) I guess this person just trusts a big company like Microsoft who keeps their source hidden more than a single developer who publishes all their source?
If any of this is relevant to you, you're already running Windows, which means Microsoft already has root on your machine, which means it's futile to try to limit the extent to which you trust their binaries.
I avoid using exceptions myself so I wouldn't be surprised if I misunderstand them :) I love to learn and welcome new knowledge and/or correction of misunderstandings if you have them.
I'll add that inspiration for the article came about because It was striking to me how Bjarne's example which was suppose to show a better way to manage resources introduced so many issues. The blog post goes over those issues and talks about possible solutions, all of which aren't great. I think however these problems with exceptions don't manifest into bigger issues because programmers just kinda learn to avoid exceptions. So, the post was trying to go into why we avoid them.
RAISI is always wrong because the whole advantage of the try block is to write a unit of code as if it can't fail so that what said unit is intended to do if no errors occur is very local.
If you really want to handle an error coming from a single operation, you can create a new function, or immediately invoke a lambda. This would remove the need break RAII and making your class more brittle to use.
You can be exhaustive with try/catch if you're willing to lose some information, whether that's catching a base exception, or use the catch all block.
If you know what all the base classes your program throws, you can centralize your catch all and recover some information using a Lippincott function.
I've done my own exploring in the past with the thought experiment of, what would a codebase which only uses exceptions for error handling look like, and can you reason with it? And I concluded you can, there's just a different mentality of how you look at your code.
No offense, but why did you decide to write an instructional article about a topic that you "wouldn't be surprised that you misunderstand"? Why are you trying to teach to others what you admittedly don't have a very solid handle on?
None taken :) I think sharing our thoughts and discussing them is how we learn and grow. The best people in their craft are those who aren't afraid to put themselves out there, even if they're wrong, how else would you find out?
"You can't handle all of them and you don't know which you'll get" is a great summary of the first two problems, and, this same problem also applies to Python. I'll add that these only start becoming an issue when you start adding more exceptions to your codebase, especially if those exceptions start appearing deep in a callstack and seemingly unrelated code starts needing to be aware of them/handle them.
The third problem (RAISI) is a C++ specific problem that Python doesn't have. Partly because in Python try/catch doesn't introduce a new scope and also partly because Python tends not to need a lot of RAII because of the nature of interpreted languages.
It's a bit more than your typical "interop via C". With a "sized opaque" type you actually can stack allocate C++ values in Zig (and vice versa stack allocate Zig values in C++), i.e.
Yeah this is correct. You don't want to pass these values around "by value" but, you should be able to "embed them" and pass "pointers to them". It's a middle-ground between a completely opaque type which you would also pass around by address, but, with the added benefit that you allocate your own storage for it.
I sort of mentioned this in the blog but this is good clarification.
> if you want to pass a shared_ptr to Zig, you need to pass a pointer to the shared pointer
Back then (a year ago?) I simply included the Windows.h header into a Zig file. Is that not possible anymore? It worked great back then for me IIRC!
Overall, I liked the build system. What I found annoying is that I had to manually search for the Windows SDK path in build.zig just so I can addIncludePath it. I needed that so I can add ICU as a dependency.
The only thing that bothered me apart from that was that producing LTO'd, stripped release builds while retaining debug symbols in a separate file was seemingly impossible. This was extra bad for Windows, where conventionally debug information is always kept in a separate file (a PDB). That just didn't work and it'd be great if that was fixed since back then (or in the near term).
Hope to be able to bring Linux back at some point. Unfortunately there wasn't enough users to justify spending development time on it. It's hard to tell if the user count was low because of lack of interest of issues with app itself. It's also ironic that Linux is the hardest platform to support. It had too many pieces outside our control that would break. If/when we can get back to it I'd like to avoid Flatpak and take an approach that we can have more control over. Possibly a static build and maybe even look into native package manager integration.
