I'd like to get back into programming after many years. I took several programming classes in school five years ago, but haven't done much since. Back then I used the gcc compiler for Unix.
I don't really know the differences between the various flavors of C++ compilers.

For those who know something about programming in C, what are the plusses and minuses of the various compilers such as Visual C++ 6.0, Visual C++ .NET, versus other available compilers. What do you use as a programmer? Why did you choose it?

Also, what version of C++ is Foobar2000 written in?

Thanks for the tips!

Well, I'm not going to get into the debate about which compiler is better, but I'm pretty certain that foobar is written in Visual C++ 6. That's what the SDK is written for, at least. (VC++.NET will automatically convert VC6 projects into the VC.NET format)

i thought that in theory all compliant C++ compilers are fine. as a programmer the most noticeable differences will be in the IDE and support libraries you use.

C++ is C++ is C++

MFC is not C++ itself - it is a bunch of classes written in C++ to help programmers of C++ programs.
Visual C++ isn't C++ itself it is an IDE and a bunch of classes written in C++ to help programmers write C++ programs with standard graphical interfaces.

i could be totally wrong

VC doesn't really have any special classes. It simply allows programmers to use classes (MFC, standard library, atl, whatever).

And also, VC isn't completely standards compliant (though I've heard VC.NET2003 is extremely compliant), but it's good enough for me.

You could try ICL, but VC++ is used by millions, has a good IDE and is pretty much a defacto standard for win32 C/C++ programming. AFAIK, there are no technical reasons for not using another dev platform. There just aren't any better alternatives out there.

I don't think Peter is using any MFC classes. Someone correct me if I'm wrong.

ICL requires VC++, so you get the IDE of VC++ and the (usually) faster ICL. Depending on your code, ICL can be up to over 50% faster than VC++ - I recently found an example of this (although most programs don't benefit THAT much form ICL).

ICL is also quite buggy. A fine example is where I've had it go bonkers when I try to compile GUI or DLL applications, and report missing symbol _main during the link process. (Entry symbol should be _WinMain or _DllMain, runtime/linker should know better than to screw up like this.) The only solution I found during those situations was to declare int main; in one of my source files.

ICL's linker also tends to explode if you should accidentally feed it old OMF OBJ files, so you will have to use MS' lib.exe to pack them up into a .LIB, and they will be converted to COFF OBJ, which you can then extract. Fun, fun, fun.

For the record, trying to build foobar2000_SDK in Dev-C++ (which uses gcc) results in this wonder gem of not workingness: B)

Edit: Took out the output, cuz it's linked down there, and it was a lot

I get the feeling that you're not showing the who build log, because the first line is "In file included from ../../pfc/string.h:4,". If you can get the full build log (for the love of God, upload it to a site, rather than posting it here. ), someone might be able to help. There's probably some minor error somewhere (perhaps in the way the dev environment is interpretting the project files. who knows) causing that landslide of shite.

Seek, and ye shall find. Ask, and it shall be given unto you.

Compile log

The imported Dev-C++ project file

Apparently someone needs to work on the line counting. :\





Hopefully someone else can help you. I don't know what the compiler's complaining about.

Find out if either the compiler or the actual dev environment might be replacing the token "xor" with "^". Maybe you've got some odd define statements in there somewhere.

I was going to add this as an edit, but the edit functino's not working for me. . .

You could use pretty much anything to code your source in, but MSVC is the only IDE I've used for creating project files and resources.

I don't actually use ICL. It is either too aggressive in optimizing or can actually generate faulty object code. I once built one of my VC++ projects with ICL 6... it caused the app to reliably crash under certain conditions. Not so with Microsoft's compiler. ICL is not worth the trouble, at least not for me.

In theory, yes, in practice no. C++ is a complex language and MSVC++ has some important differences from the ANSI standard most noteably:

1) Variables declared in for loops are scoped in the enclosing block not in the for loop block.
2) Const member initialisers are not allowed in class definitions.

In MSVC++ 7 they have actually changed the language to introduce the "managed" keyword for working with .NET, therefore this version cannot be said to be a C++ compiler.

Infact some of grosser problems can be fixed by using the /Za switch to the compiler to switch it into ANSI mode. The problem with this is that then most of the windows header files will not compile. With MSVC++ 7 you can change some of the behaviour using pragmas on a file by file basis.

The approach that gcc takes is to "fix" the system headers so that they will compile with ansi conformance switched on then use these headers in preference to the system ones.

The lastest version of the Intel compiler "knows" about everything up to P4 and can also perform automatic vectorisation of floating point code to the SSE unit. This feature was touted in 6 but only really works well in 7. It can also do cross translation unit optimisations. It can also do an attempt at automatically introducing OpenMP directives to automatically multithread code.

I have found that at least with the latest version it is only the cross translation unit optimisations which are really buggy. It is a moot points as to if all this optimisation is worth it. Depending upon the code the MSVC++ 7 compiler can be just as good code which has been specifically targeted at the P4 by icl.

I agree with most of what you said, but not this. Adding extensions to the compiler doesn't mean that it's not C++ anymore. MSVC has had MS-specific extensions for a long time. __declspec, __fastcall, and several other things. That's not where the non-compliance comes in. The non-compliance is with the things like scope.

You can disable all the managed stuff. It should then behave like VC6. I believe VC7 has improved ISO C++ compliance as well.