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 from: Adron on September 07, 2003, 09:12 AM
I use those, BC++3.1, VS97 and the DDK Build Environment (much the same as vc.net) depending on what I'm doing.
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 from: Grok on September 07, 2003, 03:33 PM
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.
That's the thing, though -
used to be. Why anybody would still want to use it right now is what I'm wondering.
Quote from: Skywing on September 07, 2003, 08:13 PM
That's the thing, though - used to be. Why anybody would still want to use it right now is what I'm wondering.
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 from: Skywing on September 07, 2003, 08:13 PMThat's the thing, though - used to be. Why anybody would still want to use it right now is what I'm wondering.
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 from: Skywing on October 27, 2003, 07:33 AM
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.
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 from: Grok on October 27, 2003, 08:07 AM
Quote from: Skywing on October 27, 2003, 07:33 AM
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.
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.
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 from: Grok on October 27, 2003, 08:07 AM
IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library.
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 from: Hostile on November 01, 2003, 10:41 AM
Quote from: Grok on October 27, 2003, 08:07 AM
IIRC, Borland had a library nomered as OWL, which maybe stood for Object Windows Library.
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. ;)
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 from: Skywing on November 01, 2003, 12:25 PM
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.
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 from: Adron on November 01, 2003, 06:36 PM
Quote from: Skywing on November 01, 2003, 12:25 PM
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.
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.
The way it was generating code resulted in virtually
all 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 from: Adron on November 01, 2003, 06:36 PMIsn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?
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 from: Kp on November 01, 2003, 11:26 PM
Quote from: Adron on November 01, 2003, 06:36 PMIsn't that the same size as any compiler would generate? Offsets are supposed to be sign-extended?
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.
Correct. This is exactly what was happening.
Quote from: Kp on November 01, 2003, 11:26 PM
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.
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 from: crashtestdummy on November 24, 2003, 05:18 AM
O.K. sorry to bring up an old post but are you all saying that visual c++ is the best compiler for windows.
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.