Here's how it works. In the early 1980s, Mr. Stroustrop and a few other people developed this variant of a C compiler over the course of several years, for their own work. As they kept adding features and changing some syntax, it became known as "C with classes". More and more things were added, some stupid stuff from C was corrected, and somewhere along the way it became C++ and the C++ standard library was born.
Now, note that C++ is a language. A language is not a compiler; and a language is NOT determined by what a particular compiler or platform implements. A language is determined by its standard.
The standard sets forth certain guarantees that each compiler must implement. However, there are a variety of machine architectures out there, each with different optimal data sizes and formats.
For example, x86 CPUs in Win32 are faster with 1-byte and 4-byte data types than with 2-byte data types. Thus MS Visual C++ implements a bool and char as 1-byte data types, and an int as a 4-byte data type. What is important to remember is that in most cases this doesn't change the way in which we use these types. For most operations, it would be okay for the compiler to implement int as an 8-byte number on platforms that performed better with 8-byte numbers.
#include <iostream>
struct some_data_struct {
bool b1, b2;
int x, y, z;
};
int main()
{
some_data_struct d;
d.b1 = true;
d.b2 = false;
// always prints "d.b1 == true"
std::cout << "d.b1 == " << ((d.b1) ? "true" : "false") << std::endl;
d.x = 10; // always 10
d.y = x * 2; // always 20
d.z = y * 2 + x; // always 50
}
That code is portable. No matter which compiler I use, it will always run as I expected when I wrote it, because it conforms the language standard. That's the beauty of a good standard!
Standards, then, are a way of telling compilers what the programmers expect, and vice versa. When a standard hits upon just the "right amount" of vagueness, programmers and compiler-writers are free to do their own jobs with minimal interference from each other.
Writing truly portable code is an art; some of the expectations or assumptions that programmers place upon their code are very hard to see if you aren't very experience with porting.
However, most expectations are quite obvious and in fact most C++ code is very portable. It's that last 5% that is filled with implicit casts, possible truncations, etc. that make for nightmares. Most developers don't need to port code; however it's good to learn something about it.
So it's generally best to program according to the C++ standard, and then adjust the code if need be to the compiler. Most people who would disagree with me on this don't know that they do it all the time; they are simply so familiar with their particular compiler or machine architecture that they don't realize it.
I second Grib's recommendation: get that book if you intend to program in C++!
Gotta go, sorry for any mistakes!
Edited by - null_pointer on March 22, 2001 6:49:41 PM
