i wanna know what you recommend for c++ programming, Visual C++, Borland C++Builder, or someother.

all i want is an opinion on what you think is better

So long as you're writing ANSI standard code, it shouldnt matter particularly what compiler or development environment you are using. It's only when you get into using specific tools and technologies (Such as the satanic MFC and Borland's equivalent of it) that it really makes a difference.

Personally I use MS Visual C++, but that's mainly because I've been using it for a long time and I'm used to it.... plus it integrates nicely with the DirectX9 SDK.

Your choice is a matter of preference.... but as I mentioned, think about any extension technologies you may wish to use before deciding.

Everyone uses VC++.

I use gcc.

I use gcc and VS.net, depending on what I'm doing.

I use those, BC++3.1, VS97 and the DDK Build Environment (much the same as vc.net) depending on what I'm doing.

[quote author=Adron link=board=5;threadid=2569;start=0#msg20476 date=1062943960]
I use those, BC++3.1, VS97 and the DDK Build Environment (much the same as vc.net) depending on what I'm doing.
[/quote]
Eww, what possible reason is there for stooping to the level of... Borland?!

So you can take advantage of the incredibly optimized and easy-to-use Visual Component Library of course!

</sarcasm>

Honestly, I have no idea either. I used Borland for a while (Sky, Kp, Yoni...maybe a few others, you probably remember that). After switching to MSVC, I haven't encountered one thing yet that Borland did better, except provide a much bulkier and totally redundant IDE.

Oh yeah...I use gcc on *Nix platform machines, MSVC7 when I'm doing the coding on my own.

Borland used to be THE compiler for PCs, until Microsoft, like they always do, used their money power to squash them by practically giving away MSC6 and MSC7, and then VC1, VC1.5, VC2. Borland tried to compete, but they couldn't compete at a loss on their product for years.

[quote author=Grok link=board=5;threadid=2569;start=0#msg20533 date=1062966835]
Borland used to be THE compiler for PCs, until Microsoft, like they always do, used their money power to squash them by practically giving away MSC6 and MSC7, and then VC1, VC1.5, VC2. Borland tried to compete, but they couldn't compete at a loss on their product for years.
[/quote]
That's the thing, though - used to be. Why anybody would still want to use it right now is what I'm wondering.

[quote author=Skywing link=board=5;threadid=2569;start=0#msg20558 date=1062983587]
That's the thing, though - used to be. Why anybody would still want to use it right now is what I'm wondering.
[/quote]

Hmm, I've just never gotten to like generating 16-bit code with Microsofts C++ compilers.

MSVC6, gcc, djgpp(very first c/c++ compiler)

[quote author=Skywing link=board=30;threadid=2569;start=0#msg20558 date=1062983587]That's the thing, though - used to be. Why anybody would still want to use it right now is what I'm wondering.[/quote]

I don't know about now, but before MSVC 32-bit compilers, Borland and Watcom were the innovators in compiler features, and Microsoft was a follower. Once Microsoft perfected their build cycles and were able to release a new compiler every 18 months or so, jam-packed with new features each time, nobody else was able to keep up. That's the story as I remember it.

There are several reasons I can think of to continue using Borland. The main one is if all your company's development was done with Borland tools and you have tens of millions of lines of code to maintain. If all your previous development was done with Borland, doing new development with Microsoft doesn't make much economical sense, unless there are features you must have from MS that don't exist in Borland today.

That should not be a problem; the code should be portable between compilers as long as you didn't get suckered into using something like VCL.

[quote author=Skywing link=board=30;threadid=2569;start=0#msg26078 date=1067261593]
That should not be a problem; the code should be portable between compilers as long as you didn't get suckered into using something like VCL.
[/quote]

IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library. I'm assuming that was their 32-bit windows sdk, but I'm making a lot of assumptions here.

[quote author=Grok link=board=30;threadid=2569;start=0#msg26081 date=1067263654]
[quote author=Skywing link=board=30;threadid=2569;start=0#msg26078 date=1067261593]
That should not be a problem; the code should be portable between compilers as long as you didn't get suckered into using something like VCL.
[/quote]

IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library. I'm assuming that was their 32-bit windows sdk, but I'm making a lot of assumptions here.
[/quote]
VCL is Borland's version of MFC. Among other things, it's known for creating absolutely huge executables for even the most simple tasks.

[quote author=Grok link=board=30;threadid=2569;start=0#msg26081 date=1067263654]
IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library.
[/quote]

And can you still see the Owl now, Grok? hehe

If I have to program in C++ I almost always use Visual C++ 6.0 EE, Visual C++.Net is basically just as nice but its pointless for the most average of applications. Unless you need some of the new technologies within it, or are going to buy a c++ compiler(since it will take longer for it to become outdated im sure, or perhaps sooner?) then don't bother. At work however we have the same but with the add-on of the Intel C++ Compiler 7.1 for Windows and Linux. Keep in mind we only have like 1 windows license and 1 for the linux compiler and ya for some reason the other guys in the office will use gcc. That compiler does make sense to learn if you ever think theres a slight chance you might become a consultant or the like at sometime because companies who need and dont yet have a compiler, often feel better if they don't have to pay for it.

PS: On a finishing note I would just like to point out that Grok uses double spaces after each sentance. We could all learn from him. ;)

[quote author=Hostile link=board=30;threadid=2569;start=15#msg26809 date=1067704914]
[quote author=Grok link=board=30;threadid=2569;start=0#msg26081 date=1067263654]
IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library.
[/quote]

And can you still see the Owl now, Grok? hehe

If I have to program in C++ I almost always use Visual C++ 6.0 EE, Visual C++.Net is basically just as nice but its pointless for the most average of applications. Unless you need some of the new technologies within it, or are going to buy a c++ compiler(since it will take longer for it to become outdated im sure, or perhaps sooner?) then don't bother. At work however we have the same but with the add-on of the Intel C++ Compiler 7.1 for Windows and Linux. Keep in mind we only have like 1 windows license and 1 for the linux compiler and ya for some reason the other guys in the office will use gcc. That compiler does make sense to learn if you ever think theres a slight chance you might become a consultant or the like at sometime because companies who need and dont yet have a compiler, often feel better if they don't have to pay for it.

PS: On a finishing note I would just like to point out that Grok uses double spaces after each sentance. We could all learn from him. ;)
[/quote]
I gave Intel C++ a try. There were some really annoying problems with it though, like generating code such that all stack variable accesses required a negative displacement, so you'd have stuff like mov eax, dword ptr [ebp+ffff3c10] all over. This was so bad that it tended to make executables 3-4 times their size with cl.exe.

Additionally, I encountered some weird linker problems that I couldn't resolve when trying to use STL.

Needless to say, despite it's nice optimize-for-speed capabilities, I don't use it.

[quote author=Skywing link=board=30;threadid=2569;start=15#msg26819 date=1067711138]

I gave Intel C++ a try. There were some really annoying problems with it though, like generating code such that all stack variable accesses required a negative displacement, so you'd have stuff like mov eax, dword ptr [ebp+ffff3c10] all over. This was so bad that it tended to make executables 3-4 times their size with cl.exe.
[/quote]

Isn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?

Also, it's normal to have negative displacement for stack variables and positive displacement for arguments when you're using a standard stack frame. See IDA's disassembly.

[quote author=Adron link=board=30;threadid=2569;start=15#msg26874 date=1067733364]
[quote author=Skywing link=board=30;threadid=2569;start=15#msg26819 date=1067711138]

I gave Intel C++ a try. There were some really annoying problems with it though, like generating code such that all stack variable accesses required a negative displacement, so you'd have stuff like mov eax, dword ptr [ebp+ffff3c10] all over. This was so bad that it tended to make executables 3-4 times their size with cl.exe.
[/quote]

Isn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?

Also, it's normal to have negative displacement for stack variables and positive displacement for arguments when you're using a standard stack frame. See IDA's disassembly.
[/quote]
The way it was generating code resulted in virtually [u]all[/u] functions requiring four byte displacements for locals access. It managed to turn a 30K program into a 400K one, and that's with dynamic linking to the runtime (release build, all debugging information off). I verified this with disassembly, FYI.

[quote author=Adron link=board=30;threadid=2569;start=15#msg26874 date=1067733364]Isn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?[/quote]As I understand it, the compiler was doing the sign-extension into a full 32 bits and writing *that* as the offset in the binary, as opposed to writing a byte with the sign bit set and trusting the CPU to sign extend it at run time.

[quote author=Kp link=board=30;threadid=2569;start=15#msg26961 date=1067750797]
[quote author=Adron link=board=30;threadid=2569;start=15#msg26874 date=1067733364]Isn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?[/quote]As I understand it, the compiler was doing the sign-extension into a full 32 bits and writing *that* as the offset in the binary, as opposed to writing a byte with the sign bit set and trusting the CPU to sign extend it at run time.
[/quote]
Correct. This is exactly what was happening.

[quote author=Kp link=board=30;threadid=2569;start=15#msg26961 date=1067750797]
As I understand it, the compiler was doing the sign-extension into a full 32 bits and writing *that* as the offset in the binary, as opposed to writing a byte with the sign bit set and trusting the CPU to sign extend it at run time.
[/quote]

Ah. In that case, Skywing just gave a bad example. There's no way that his offset "mov eax, dword ptr [ebp+ffff3c10]" could fit into less than a full dword in any compiler.

O.K. sorry to bring up an old post but are you all saying that visual c++ is the best compiler for windows.
Also, what are your favorite books?

[quote author=crashtestdummy link=board=30;threadid=2569;start=15#msg31072 date=1069672703]
O.K. sorry to bring up an old post but are you all saying that visual c++ is the best compiler for windows.[/quote]

I wouldn't say that, in part because it's an ambiguous statement. Are you referring to VC++ 5 (eww), VC++ 6, or VC++ 7 (the ".Net" version)? It's impossible for all three of them to be simultaneously best, and I would definitely suggest comparing what each of them offers/doesn't offer in both user interface and language extensions/compiler analysis. From some of the output Skywing has showed me from VC++ 7, it seems to be very smart about code flow analysis. On the other hand, the last time I checked, it was prone to occasionally generating incorrect executables from perfectly valid source code.