A small request when posting headings for each forum, if you can include subject the forum/chapter covers. I will be joining later when you start covering OOP, Pointers..etc.. '-]
example: C++ Workshop - Week 5 (Ch. 8) "Pointers, Refernce"
I stumbled across this thread three days ago, bought the book on the following day and have worked through the first two chapters over the weekend so I'm waiting eagerly for the next phase of the workshop. It's a fantastic idea - thanks to all concerned!
I have Dev-C++ 4.9.9.2 but can't get it to debug. I can compile code with it so I'll have to wade through the guidelines about setting up Dev-C++. I also have VCEE and am delighted that I can actually create an .exe with the detailed instructions that I've read here. I was almost at the stage of uninstalling it and taking up flower arranging!
The reason for my slight preference of Dev-C++ over VCEE? I've heard that an .exe created with VCEE can't be transferred to another PC which doesn't have it installed. Is that correct and does it apply to all .exe files that I might create with VCEE? Whilst I am nowhere near to creating anything to distribute (even to friends), I may progress to that so how would I go about creating something for distribution to a PC which doesn't have anything "special" installed? I wouldn't like to go all the way down the VCEE route if the only solution would be to get a different compiler and have to learn all the idiosyncrasies that it may have.
Thanks once again and here's to the next phase for us all.
Glad to hear you're following along, and I hope the workshop can be of use to you.
As for what you heard about .exe files created with VC++, nothing can be further from the truth. Both Visual C++ and Dev-C++ are ANSI/ISO compatible compilers, which generate suitable compiled executables on a chosen platform.
C++ is a native language, compiled down to machine code, which means that a C++ program, compiled with ANY ANSI/ISO compiler can run on any architecture for which it was compiled for. This is generally operating system and platform specific, however. So you cannot take a C++ program built for Windows and expect to run it on Linux. Linux uses an ELF format which is different from the Windows executables and they in general, wont run on the opposite platforms.
Now, Visual Studio does allow you to use the .NET Framework which is a managed architecture that generates an Intermediate Language (IL) as opposed to a native binary. As a result, programs written in C# or C++/CLR will only run on machines and operating systems that have a CLR running. But note, C++/CLR is NOT the same as ISO C++ which we use within this course, and so you should not fear your C++ executables can't be run on other people's computers. They will work just fine. If that's the only reason you were afraid to use the Visual C++ compiler, then go ahead and get comfortable with it, there's nothing to worry about.
What I meant about some form of incompatibility between Windows PCs relates to Visual C++ Express Edition, rather than Visual C++. I appreciate that an .exe created with Visual C++ on my Windows XP PC would work on another XP PC "out of the box" and without anything extra having been in installed but it wouldn't work on a Linux or Mac computer. Does the same apply to an .exe created with Visual C++ Express Edition?
Apologies if my interpretation of what I've read elsewhere is incorrect. I've not had to opportunity of trying my "Hello World!" (created with Visual C++ Express Edition) on a different PC. According to what I've seen elsewhere, it shouldn't work. If that's correct, I would have to purchase the standard Visual C++, wouldn't I?
Original post by CondorMan Does the same apply to an .exe created with Visual C++ Express Edition?
If the correct run-time libraries are installed on the target machine, or are included along with the executable, then yes, the program will run. Otherwise, it's like trying to play a DirectX game without having DirectX installed...
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
So, if and when it comes to it, I'll make sure that the correct libraries are packaged with the .exe as I won't have control over what's on the other PC.
1. The runtime libraries can be linked statically, which shouldn’t require you to package anything. As well, if the end-user has ever ran any WinXP application before, they've likely already got all necessary libraries. Its important to realize that fully 90% of all software developed for Windows has been developed using Visual Studio. So it's not like because you're using Visual C++ you're suddenly in the minority. In fact, Dev-C++ has SIGNFICANTLY fewer developers than VC++.
2. This problem is NOT compiler related. It's operating system related. Windows breaks up all its functionality into dynamic libraries to make for smaller executables and shared resources. Any application developed for windows will have the same problem(s), regardless of which compiler you're using. With that said, Microsoft does include with its Platform SDK functions, classes, etc...which only work on XP. Using these will definitely prevent your application from being run on other versions of windows. But the solution is quite simple, don’t use those components and your application will remain portable across operating system versions. And again...using those components from the Platform SDK will prevent your application from being portable, even if you built your application using Dev-C++.