6 ms·

> The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. we certainly have a different opinion on w

> The title of this article had me do a double-take: C and C++ development on Windows is great. No sanity is needed. we certainly have a different opinion on what "great" means. It takes less time to rebuild my whole toolchain from scratch on Linux (~15 minutes) than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something (I sometimes have to wait 30-40 minutes and I'm on friggin 2GB fiber ! and that's seemingly every time I have to do something with that wretched MSVC !) Thankfully now the clang / lld / libc++ / lldb ... toolchain works pretty well on Windows and allows a lot more sanity but still, it's pretty slow compared to Linux.

liversage 5y ago
I agree that downloading symbols can be oddly slow but you can just turn it off, or only turn it on for specific modules. It can be helpful to have symbols for library code to troubleshoot bugs but typically you only need your own symbols and they are already on your computer with your binaries.
gavinray 5y ago
I just use the LLVM toolchain -- on Windows and Linux. You really can't beat clang and lld, the ecosystem and tooling is fantastic. If something absolutely requires MSVC ABI compatibility, I use "clang-cl". God bless LLVM developers.
- pjmlp 5y ago
  That is why they are now lagging behind everyone else on C++20 support.
torginus 5y ago
My main gripe with writing C++ on Linux is the dependency management. If you need to do stuff that's not covered by the standard library, like interfacing with GTK or X11 you are in a world of pain. You need to probably install a distro-specific package in a distro-specific way to get the headers/symbols, use some build tool to configure those distro-specific include/so locations, and hope to god that the distro maintainers didn't upgrade one of those packages (in a breaking way) between the source commit and the time of build. If you suffer through this, you have an exe that works on your version of Ubuntu, maybe on other versions of Ubuntu or possibly other Debian-based distros. If you want it to also work on Fedora, it's back to tinkering. Tbh i think the only sane-ish way of building to dockerize your build env with baked-in versions. In contrast, you pick and SDK and compiler version for Windows, and as long as you install those versions, things will work.
- CountSessine 5y ago
  Versus no dependency management at all? This reasoning falls apart once you need to use a 3rd party library on Windows. There’s no standard way of sharing such a thing so you always wind up packaging the whole thing with your program, and handing the whole mess to your users. Granted, writing an RPM is a special kind of hell, but at least you don’t have to package everything with your program. But actually you can still do that - I’ve done that plenty of times in embedded. You can always ship your program with its dependant libraries the way you always have to on Windows. In fact it’s a lot easier because most 3rd party libraries were originally coded on Linux and build more sanely on Linux. And RPATHs are pretty easy to figure out. Linux gives you options.
  - torginus 5y ago
    Yeah, you're right, but you probably need a lot less stuff that's not in the SDK. My go to solution for including dependencies, is just checking in all the dependency .lib, include files into Git LFS (I think this is a rather common approach from what I've seen on Git). For your typical Linux C/C++ project, unless it's made by best in class C++ devs, building can be a pain, most likely because it depends on very particular lib versions, building a largish project from GitHub for Ubuntu 21.10, where the original dev used 20.04 is usually not possible without source/Makefile tweaks. And I don't particularly love the idea of using root access to install packages to just build some random person's project. IMHO, C++ dependency management kinda stinks, regardless of platform.
    - nicoburns 5y ago
      > IMHO, C++ dependency management kinda stinks, regardless of platform. Indeed, and the fact that it's platform-specific in the first place certainly doesn't help!
  - dgfitz 5y ago
    Writing an rpm isn’t difficult… is that a commonly held belief? Maybe I don’t know what I don’t know, but I’ve found wrapping my head around deb packaging much harder than rpms.
SloopJon 5y ago
> Thankfully now the clang / lld / libc++ / lldb ... toolchain works pretty well on Windows Off topic, but I wonder if anyone knows whether it's possible to use rustc with lld, instead of link.exe? I tend not to have Visual C++ on my home systems. Is it as simple as the Cargo equivalent of LD=lld-link.exe?
- ChrisSD 5y ago
  You would need libraries. E.g. the C runtime and system import libraries (msvcrt.lib, vcruntime.lib, kernel32.lib, etc).
simplestats 5y ago
Microsoft is certainly evil and all, but I use MSVC on windows and clang on linux and the Windows tools for my project are much smarter and faster when it comes to compiling. Not counting times when the windows machine decides it has more important priorities to attend to rather than doing what I need.
TinkersW 5y ago
Debug symbols are stored locally with MSVC, and booting into debug mode only takes a few seconds longer than non-debug, sounds like you are doing something wrong.
badsectoracula 5y ago
> It takes less time to rebuild my whole toolchain from scratch on Linux (~15 minutes) than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something Fun fact: you can do the same in gdb and some distributions (e.g. openSUSE) have it enabled by default. Though you also get the source code too. I was messing around with DRM/KMS the other day and had some weird issue with an error code, so i placed a breakpoint right before the call - gdb downloaded libdrm and libgbm source code (as well as some other stuff) and let me trace the call right into their code, which was super useful to figure out what was going on (and find a tiny bug in libgbm, which i patched and reported).
- aseipp 5y ago
  Yes, it's a relatively recent innovation, but it's pretty awesome. Symbol server has always been one of the things I actually liked about Windows development, which didn't require installing debug packages for every DLL before the bugs happen and you catch them. https://sourceware.org/elfutils/Debuginfod.html https://sourceware.org/elfutils/Debuginfod.html NixOS has had a similar thing for a while called "DwarfFS" where a FUSE filesystem instead resolves filenames back to the package that needs to be installed, which was around for a while before debuginfod, but very NixOS specific. I'm happy this is now so much more widely available as of recently.
fsloth 5y ago
"than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something" I think you can just unclick the radio button in debug settings that requires that?
modeless 5y ago
Really? I've never had to wait more than 5 minutes, and only the first time since the symbols are cached. On the other hand, the Visual Studio debugger actually works, even on large and complex multi-process systems like Chromium. My experience debugging C/C++ with GDB/LLDB and any frontend using them has been so poor that I've essentially given up trying them in all but the most desperate circumstances.
banachtarski 5y ago
I couldn’t disagree more with your opinion. Symbol servers and pdbs are a tremendous advantage to C and C++ development on Windows. Are you sure you have equivalent experience with both Windows and non-MSVC toolchains?

liversage 5y ago

I agree that downloading symbols can be oddly slow but you can just turn it off, or only turn it on for specific modules. It can be helpful to have symbols for library code to troubleshoot bugs but typically you only need your own symbols and they are already on your computer with your binaries.

gavinray 5y ago

I just use the LLVM toolchain -- on Windows and Linux. You really can't beat clang and lld, the ecosystem and tooling is fantastic. If something absolutely requires MSVC ABI compatibility, I use "clang-cl". God bless LLVM developers.

pjmlp 5y ago
That is why they are now lagging behind everyone else on C++20 support.

torginus 5y ago

My main gripe with writing C++ on Linux is the dependency management. If you need to do stuff that's not covered by the standard library, like interfacing with GTK or X11 you are in a world of pain. You need to probably install a distro-specific package in a distro-specific way to get the headers/symbols, use some build tool to configure those distro-specific include/so locations, and hope to god that the distro maintainers didn't upgrade one of those packages (in a breaking way) between the source commit and the time of build. If you suffer through this, you have an exe that works on your version of Ubuntu, maybe on other versions of Ubuntu or possibly other Debian-based distros. If you want it to also work on Fedora, it's back to tinkering. Tbh i think the only sane-ish way of building to dockerize your build env with baked-in versions. In contrast, you pick and SDK and compiler version for Windows, and as long as you install those versions, things will work.

CountSessine 5y ago
Versus no dependency management at all? This reasoning falls apart once you need to use a 3rd party library on Windows. There’s no standard way of sharing such a thing so you always wind up packaging the whole thing with your program, and handing the whole mess to your users. Granted, writing an RPM is a special kind of hell, but at least you don’t have to package everything with your program. But actually you can still do that - I’ve done that plenty of times in embedded. You can always ship your program with its dependant libraries the way you always have to on Windows. In fact it’s a lot easier because most 3rd party libraries were originally coded on Linux and build more sanely on Linux. And RPATHs are pretty easy to figure out. Linux gives you options.
- torginus 5y ago
  Yeah, you're right, but you probably need a lot less stuff that's not in the SDK. My go to solution for including dependencies, is just checking in all the dependency .lib, include files into Git LFS (I think this is a rather common approach from what I've seen on Git). For your typical Linux C/C++ project, unless it's made by best in class C++ devs, building can be a pain, most likely because it depends on very particular lib versions, building a largish project from GitHub for Ubuntu 21.10, where the original dev used 20.04 is usually not possible without source/Makefile tweaks. And I don't particularly love the idea of using root access to install packages to just build some random person's project. IMHO, C++ dependency management kinda stinks, regardless of platform.
  - nicoburns 5y ago
    > IMHO, C++ dependency management kinda stinks, regardless of platform. Indeed, and the fact that it's platform-specific in the first place certainly doesn't help!
- dgfitz 5y ago
  Writing an rpm isn’t difficult… is that a commonly held belief? Maybe I don’t know what I don’t know, but I’ve found wrapping my head around deb packaging much harder than rpms.

SloopJon 5y ago

> Thankfully now the clang / lld / libc++ / lldb ... toolchain works pretty well on Windows Off topic, but I wonder if anyone knows whether it's possible to use rustc with lld, instead of link.exe? I tend not to have Visual C++ on my home systems. Is it as simple as the Cargo equivalent of LD=lld-link.exe?

ChrisSD 5y ago
You would need libraries. E.g. the C runtime and system import libraries (msvcrt.lib, vcruntime.lib, kernel32.lib, etc).

simplestats 5y ago

Microsoft is certainly evil and all, but I use MSVC on windows and clang on linux and the Windows tools for my project are much smarter and faster when it comes to compiling. Not counting times when the windows machine decides it has more important priorities to attend to rather than doing what I need.

TinkersW 5y ago

Debug symbols are stored locally with MSVC, and booting into debug mode only takes a few seconds longer than non-debug, sounds like you are doing something wrong.

badsectoracula 5y ago

> It takes less time to rebuild my whole toolchain from scratch on Linux (~15 minutes) than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something Fun fact: you can do the same in gdb and some distributions (e.g. openSUSE) have it enabled by default. Though you also get the source code too. I was messing around with DRM/KMS the other day and had some weird issue with an error code, so i placed a breakpoint right before the call - gdb downloaded libdrm and libgbm source code (as well as some other stuff) and let me trace the call right into their code, which was super useful to figure out what was going on (and find a tiny bug in libgbm, which i patched and reported).

aseipp 5y ago
Yes, it's a relatively recent innovation, but it's pretty awesome. Symbol server has always been one of the things I actually liked about Windows development, which didn't require installing debug packages for every DLL before the bugs happen and you catch them. https://sourceware.org/elfutils/Debuginfod.html https://sourceware.org/elfutils/Debuginfod.html NixOS has had a similar thing for a while called "DwarfFS" where a FUSE filesystem instead resolves filenames back to the package that needs to be installed, which was around for a while before debuginfod, but very NixOS specific. I'm happy this is now so much more widely available as of recently.

fsloth 5y ago

"than it takes to MSVC to download those friggin debug symbols it seems to require whenever I have to debug something" I think you can just unclick the radio button in debug settings that requires that?

modeless 5y ago

Really? I've never had to wait more than 5 minutes, and only the first time since the symbols are cached. On the other hand, the Visual Studio debugger actually works, even on large and complex multi-process systems like Chromium. My experience debugging C/C++ with GDB/LLDB and any frontend using them has been so poor that I've essentially given up trying them in all but the most desperate circumstances.

banachtarski 5y ago

I couldn’t disagree more with your opinion. Symbol servers and pdbs are a tremendous advantage to C and C++ development on Windows. Are you sure you have equivalent experience with both Windows and non-MSVC toolchains?