59 ms·

So why not use gcc or mingw? Is it just the IDE or are there other complications? I haven't developed natively on Windows since the Borland TurboC++ days, so I'

So why not use gcc or mingw? Is it just the IDE or are there other complications? I haven't developed natively on Windows since the Borland TurboC++ days, so I'm kind out out of the loop there.

breckinloggins 15y ago
- The VC compiler is actually really good, especially for Windows code (obviously) - Visual Studio is a great IDE but more importantly it's what MS devs are used to. It's harder to attract good MS developers if you don't support Visual Studio - Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) - Gcc/mingw setup on Windows is perceived as more complex than installing VS
- jhasse 15y ago
  >- Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) If you aren't using C++, everything should work fine. I've been using C binaries from VS and mingw together without problems :)
  - excuse-me 15y ago
    'C' doesn't have name mangling Mixing C++ binaries from different compilers is much trickier
radarsat1 15y ago
I would like to, but from my experience thus far of writing a C library and using some C99'isms, then doing a bunch of work to port it to Windows: Windows developers are not satisfied with something working on Windows, they want to be able to compile it in Visual Studio or they won't use it. Don't know how generalisable this is, but all I know is that I'm forced to go back and remove any C99 from my code if I want my library to be used on Windows, despite the fact that the binaries I distribute work fine. Well, I can't blame them for wanting to use their tools of choice, but as a developer wanting his work to be compatible with the most popular platform, it's an unfortunate situation.
mkup 15y ago
MSVC has very powerful debugger. It is able to inspect STL collections, set conditional breakpoints, break on certain types of exceptions, watch complex expressions, view local variables by mouse hover etc. It can attach to running process, it may be closed-source process with my DLL, and I would be able to do source-level debugging for that DLL. I usually compile outside of IDE (from command line / Far Manager) with custom build script and use MSVC only as a debugger: it has nice feature of opening EXE file as a project workspace. We're stuck with MSVC until gcc and its Windows ports will have a decent GUI debugger.
- simoncion 15y ago
  Aside from the great STL container inspection (There are claims that macros exist to make container inspection nice. There is also set prettyprint.), you can do all that in gdb. If you like IDEs you can use Eclipse and CDT, which has a frontend to gdb that works just as well as VS's debugger.
  - aidenn0 15y ago
    Sorry, but gdb and eclipse are crap for C/C++ development. There is nothing you can do in MSVC that you can't do more slowly in a less-obvious manner in either gdb or eclipse.
    - simoncion 15y ago
      I spent five years doing C++ work in VS 6 through VS 9. I've spent a little more than a year doing C++ work with Eclipse 3.6 and what appears to be CDT 7.x. After figuring out (and changing, where needed) the default keybindings, I find that neither development nor debugging is any slower in Eclipse than it was in VS 8->9. (Don't get me started about the dog that was VS 6.) Also, there are quite a few things that stymied VS (such as "go to class definition") that CDT gets right every time. Anecdata FTL, I guess. Note that the CDT of long ago was absolute trash. If you haven't tried it in the past couple of years, get a recent version of Eclipse and try again. It's really a good tool.

So why not use gcc or mingw? Is it just the IDE or are there other complications? I haven't developed natively on Windows since the Borland TurboC++ days, so I'm kind out out of the loop there.

breckinloggins 15y ago

- The VC compiler is actually really good, especially for Windows code (obviously) - Visual Studio is a great IDE but more importantly it's what MS devs are used to. It's harder to attract good MS developers if you don't support Visual Studio - Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) - Gcc/mingw setup on Windows is perceived as more complex than installing VS

jhasse 15y ago
>- Binary compatibility issues between stuff compiled with gcc/mingw and stuff compiled with VS (??? Someone chime in here if I'm wrong) If you aren't using C++, everything should work fine. I've been using C binaries from VS and mingw together without problems :)
- excuse-me 15y ago
  'C' doesn't have name mangling Mixing C++ binaries from different compilers is much trickier

radarsat1 15y ago

I would like to, but from my experience thus far of writing a C library and using some C99'isms, then doing a bunch of work to port it to Windows: Windows developers are not satisfied with something working on Windows, they want to be able to compile it in Visual Studio or they won't use it. Don't know how generalisable this is, but all I know is that I'm forced to go back and remove any C99 from my code if I want my library to be used on Windows, despite the fact that the binaries I distribute work fine. Well, I can't blame them for wanting to use their tools of choice, but as a developer wanting his work to be compatible with the most popular platform, it's an unfortunate situation.

mkup 15y ago

MSVC has very powerful debugger. It is able to inspect STL collections, set conditional breakpoints, break on certain types of exceptions, watch complex expressions, view local variables by mouse hover etc. It can attach to running process, it may be closed-source process with my DLL, and I would be able to do source-level debugging for that DLL. I usually compile outside of IDE (from command line / Far Manager) with custom build script and use MSVC only as a debugger: it has nice feature of opening EXE file as a project workspace. We're stuck with MSVC until gcc and its Windows ports will have a decent GUI debugger.

simoncion 15y ago
Aside from the great STL container inspection (There are claims that macros exist to make container inspection nice. There is also set prettyprint.), you can do all that in gdb. If you like IDEs you can use Eclipse and CDT, which has a frontend to gdb that works just as well as VS's debugger.
- aidenn0 15y ago
  Sorry, but gdb and eclipse are crap for C/C++ development. There is nothing you can do in MSVC that you can't do more slowly in a less-obvious manner in either gdb or eclipse.
  - simoncion 15y ago
    I spent five years doing C++ work in VS 6 through VS 9. I've spent a little more than a year doing C++ work with Eclipse 3.6 and what appears to be CDT 7.x. After figuring out (and changing, where needed) the default keybindings, I find that neither development nor debugging is any slower in Eclipse than it was in VS 8->9. (Don't get me started about the dog that was VS 6.) Also, there are quite a few things that stymied VS (such as "go to class definition") that CDT gets right every time. Anecdata FTL, I guess. Note that the CDT of long ago was absolute trash. If you haven't tried it in the past couple of years, get a recent version of Eclipse and try again. It's really a good tool.