C++/Visual C++ or C++?
QUESTION: Ok, this question has probably been asked several times but I'll ask it again because everyone thinks they are in a different situation.
Question: I have some experience in programming including PASCAL, BASIC and some in MATLAB as part of my curriculum.
So programming is not new to me. However, I am confused as to which one I should use. I know that both C++ and Visual C++ are used in the financial industry. I just downloaded the Visual C++ express edition along with Visual Basic Express and SQL Server Express that Microsoft offers for free. I do intend to start from there.
So could you tell me if I should use C++ or Visual C++? My concern is not being able to use C++ if I start with Visual C++, or the other way around.
Also, what are the benefits of using either? Please advise!
ANSWER: OK, let me clear up some terminology.
C++ is a computer programming language. It is free to anyone to implement, and its standard definition is currently governed by the ISO C++ standard of 2003 (the Technical Corrigendum 1 'bug fix' update from the original 1998 standard).
Microsoft Visual C++ is a specific product. It is an implementation of C++ that can to a large degree compile standard C++ (the degree of compliance depends on the version - the current 2005/8.0 version editions are really quite good in this respect). I should note that no (or very, very few) implementations of C++ are 100% compliant with the ISO standard C++.
However in addition to the standard C++ features, the core C++ language and its supporting library (or libraries depending on how you look at it/them) Visual C++ includes both core language features and additional libraries that are Microsoft specific. These libraries and additional features cover support for things such as Windows applications and COM development. Then of course there is .NET interoperability in the form of language extensions (new to the 2005/8.0 version) called C++/CLI which Microsoft submitted to ECMA for standardisation (which follows their practice for some other parts of .NET). There is also the Windows platform SDK which is the C interface to the Windows operating system facilities (which I believe is a separate download if you are using the free express edition).
So you can use Visual C++ for either as standard C++ development as is possible with the given compiler or for some form of development that requires Microsoft specific features.
If you choose to make use of Microsoft specific libraries - the MFC or ATL - then your code will be reliant on those libraries. This may not be a bad thing. If your application is only intended for Microsoft operating systems then this is not going to be much of a problem. The problems start when you wish to port your code to another compiler that does not have these libraries available. Note that this does not just apply to the Microsoft libraries but to _any_ library. If a library your code makes use of is not available for some compiler/platform combination then you are not going to build your code using that combination, at least not without some (possible a whole lot) of work.
Likewise if you choose to write non-standard C++ using Microsoft specific core language features - such as C++/CLI - then your code is locked into compilers that can understand these extensions. As far as I know at the time of writing _only_ Visual C++ 2005 has support for C++/CLI. Again this may not be a bad thing if you only intend to use Visual C++ or later as your compiler for you projects.
However I think that the most important thing with any additional libraries or language extensions is to _know_ when you are using them and that they are non-standard, taking precautions if the risk is high enough. The usual approach if you think your code may need to be built using another compiler possibly on a different operating system that may not have some of the facilities you are using is to have a well defined interface between code that uses compiler/platform/library specific features or extensions and code that is as standard as possible. That way you only have to re-write the parts on the non-standard side of the interface each time. At least that is the theory, see below...
Other annoying things are:
1/ as I said most C++ compilers are not fully 100% compliant with the standard, and they can be not 100% compliant in annoyingly different ways. Also, compilers are software, and like all software they can have bugs. So you will find that you may need to use a common subset of the standard language in your code that is the part of C++ that all target compilers agree upon. If you are using newer compilers only then this is less of a problem as they have had time to get closer to the standard.
2/ certain parts of C++ are compiler specific. Examples are the size of integers and whether the char type for characters (and small integer values) is signed or not by default. One such difference I came across recently is that wchar_t - the type used for wide characters - demonstrably differs among the platforms I was interested in supporting. On Win32 systems (and Win64) it is a 16-bit integer (and holds UTF16 encoded characters) whereas on a 64-bit version of Linux using the GNU g++ 4.0.2 compiler it turned out to be a 32-bit integer (presumably holding UTF32 or UCS4 encoded characters). Note that even assuming a char is 8-bits in size and that a null pointer really does have a value of zero is not guaranteed, although in practice on most common modern desktop, workstation or server systems these are likely to be true.
Other common mistakes are that int and long int are going to be 32 bits in size, that the size of a pointer is going to be the same as the size of an int - such things only tend to be true on 32-bit systems. On 64-bit systems for example things tend to vary depending on what 64-bit model a compiler adopts. For Visual C++ (and Win64) for example int and long int are still 32-bits in size (only the non standard __int64 and its more common pseudonym long long int are 64-bits in size), but pointers are 64-bits in size. Other compilers adopt different sizes, another common one is that int is 32-bits and long int and pointers are 64-bits (see for example http://www.unix.org/whitepapers/64bit.html
for more information of 32-bit and 64-bit data models).
Because of all these differences and scope for writing non-standard code I try to ensure supposedly standard C++ code is compiled using more than one compiler, on different platforms if possible. Currently I use Visual C++ 2005 32-bit and 64-bit and (as mentioned previously) g++ 4.0.2 under 64-bit Linux. Both using x64 processors though. Another benefit of using two or more compilers is that they have different error messages (although hopefully for the same errors) and some compilers' error messages give a more obvious hint of the error than others (Visual C++ I find can tend to the cryptic at times).
[an error occurred while processing this directive]---------- FOLLOW-UP ----------
QUESTION: Thanks so much. So bottom line is that I can use Visual C++ to create codes that could be written without Visual C++ (i.e. old school 32 bit C++ codes for Windows) and ALSO write codes that are needed to create programs specifically for the Microsoft .NET framework or 64 bit applications?
THANKS SO MUCH!!!!
You've been a great help!
Basically yes. Although you will have to check the feature matrix for the current version of Visual C++ (i.e. 2005 version) on the MS web site to see which edition has which features. I suspect the free edition does not have 64-bit target build support for example. In fact I have found you have ask for it to be installed with the paid for version when installing VC++ 2005 as they are not installed by default, even if you are running a 64-bit version of Windows XP or Vista.
Note that .NET applications are referred to as ‘managed’ and normal C++ applications are referred to as ‘native’ in the MS documentation. See the Visual C++ Express pages on the MS site at http://msdn.microsoft.com/vstudio/express/visualc/
for more information - especially this bit http://msdn.microsoft.com/vstudio/express/visualc/features/language/default.aspx
(it looks like the Express edition may not include Microsoft specific MFC or ATL libraries but I have not tracked down the full feature set as of yet – you are the one using it I suggest you check out what you have got <g>!).