Cygwin vs. MinGW

[akatechis]

I'm looking to learn the intricacies of C++ (already know Java well enough to call myself an experienced developer in that environment) and I don't want to learn it the "wrong" way with a bunch of Microsoft specific libraries of VCC.

That said, which windows port of gc++ and its associated tools (debugger, make, etc.) is better? And by better I mean stable, as I will be using with Eclipse IDE on Windows 7 Ultimate, 32bit Edition.

I'm also open to other GCC ports (assuming they are reliable), if there are any.

 

[Ken g6]

Pretty much the biggest difference is that Cygwin-compiled binaries require Cygwin DLLs if you distribute them. Cygwin is easier to set up, but with enough work, MinGW with MSYS works fine too.

Make is probably the biggest difficulty you listed there. I've always had to run it within a BASH shell. But it seems like Eclipse ought to take over for make, shouldn't it?

 

[akatechis]

I think I will go with Cygwin. After doing some more searching, I found some eclipse documentation which suggests that Cygwin is a more complete implementation of the GNU libc C library runtime.

I will post again if I come across any significant difficulties in getting this set up.

 

[Nothinman]

You might also want to consider a full Linux VM. You'll have a lot more tools at your disposal and you can mix some Linux experience in there too. =)

 

[Cogman]

Cygwin = lets put unix on windows, use as much native unix stuff as possible
MingW = lets keep unix out of windows as much as possible, us as much native windows stuff as possible.

Cygwin is usually a little bit slower because it adds a couple of extra layers, where as mingw is generally pretty good about doing the bare minimum of stuff.

As for the "bunch of Microsoft specific libraries of VCC.", you only use those libraries if you want to. The microsoft Visual C++ compiler is pretty good about Ansi standards, thus most code that compiles with Mingw compiles with microsofts compiler without many issues.

As nothing man said, if you want a linux environment (GNU libc stuff) then you probably should just do a linux VM. I've done some pretty intense programming and dealt with some pretty low level code, honestly, either compiler is going to do everything you need it to do, I doubt that you will ever run into a huge life altering difference between the two (so long as you don't do GNU/microsoft specific code.)

When you run into specific problems is when you start to try playing with OS specific stuff (playing sound, making windows, ect). There is NO ansi C++ standard for OS interaction (well, threading is going to be part of the standard here soon, but that's a bit off topic). Truth be told, I actually prefer a lot of the win32 API OS calls over the GNU calls. Try making a window with raw XLib code vs using the Win32 code, the difference is huge (And that is the correct comparison, mentioning the GTK or QT is not a direct comparison.) Win32 code, while slightly opaque, is miles easier to write then xlib code.

 

[Nothinman]

Try making a window with raw XLib code vs using the Win32 code, the difference is huge (And that is the correct comparison, mentioning the GTK or QT is not a direct comparison.) Win32 code, while slightly opaque, is miles easier to write then xlib code.

Except that I don't think any sane person would recommend that you use straight Win32 or Xlib to draw windows. That's the whole point of the higher level libraries.

 

[Net]

i like cygwin for writing small pieces of code that i know i won't have to debug that much.

when you start writing c++ programs with objects on the heap, etc.. a good ide can save you a lot of time and make the debugging experience much more pleasant.

if your past learning the basic for loops and if statements look into a solid ide. there a free ones out there. eclipse uses g++/gcc and also gdb for the debugger.

 

[Cogman]

Except that I don't think any sane person would recommend that you use straight Win32 or Xlib to draw windows. That's the whole point of the higher level libraries.

Performance code on embedded systems. Or even someone that doesn't want a simple window to be over 3 mb big.

Heck, If I'm writing a game, I don't want all the extra garbage that comes along with the GTK tagging along. My personal opinion is that everyone should make a window, at least once, with native OS calls, just to see how much has to be done and understand what is really going on in the background of their higher level window libraries.

BTW, IMO a window created with native Win32 calls is about on the level of difficulty as using the GTK to do the same thing. Xlib is miles more complex then anything else, that is partially due to the fact that it was developed to be a multi-client server.

 

[squatchman]

I think the biggest difference I've noticed between cygwin and mingw is the use of bash for writing build scripts.

Please don't do that, for the love of every poor prick that has to look at what you write months and years down the road.

 

[Cogman]

I think the biggest difference I've noticed between cygwin and mingw is the use of bash for writing build scripts.

Please don't do that, for the love of every poor prick that has to look at what you write months and years down the road.

Mingw (through mysys) supports bash scripts. If you use autotools to create your building script, I don't see what the big deal is.

 

[squatchman]

I keep things simple and platform independent. You can do whatever you want.

Aside from the obvious problem that people will make mistakes and somehow tie their buildscripts to the local machine, you're forced to install additional packages to get the thing running.

It wouldn't be a problem if all developers documented their environments and the packages required to build, but a cursory glance at the sources/makefiles won't tell you if a particular package requires: mingw, mingw/msys, cygwin, or some esoteric combination of the hundreds of cygwin packages available.

 

[degibson]

As for the "bunch of Microsoft specific libraries of VCC.", you only use those libraries if you want to. The microsoft Visual C++ compiler is pretty good about Ansi standards...

I agree with this. Don't worry too much about your environment when you're trying to learn the language itself. All environments have their own quirks, and no environment is any more correct than another (among those environments that are ANSI-complaint).

I suggest you pick the tools that help you learn, the environment notwithstanding.

 

[Cogman]

I keep things simple and platform independent. You can do whatever you want.

Aside from the obvious problem that people will make mistakes and somehow tie their buildscripts to the local machine, you're forced to install additional packages to get the thing running.

It wouldn't be a problem if all developers documented their environments and the packages required to build, but a cursory glance at the sources/makefiles won't tell you if a particular package requires: mingw, mingw/msys, cygwin, or some esoteric combination of the hundreds of cygwin packages available.

You might want to look up how the GNU building environment works. I agree, that making your own build scripts should generally be avoided, however, the GNU standard for build scripts is pretty solid and very widely used. Pretty much all of them are setup the same way, from the GCC to firefox, the standard installation is ./configure && make && make install.

You should know what packages you build your projects with, if you don't, you're in big trouble.