Thinking in C plus plus (P8) pptx

330 Thinking in C++ www.BruceEckel.com class X { void f(); }; the function f( ) inside the scope of class X does not clash with the global version of f( ) . The compiler performs this scoping by manufacturing different internal names for the global version of f( ) and X::f( ) . In Chapter 4, it was suggested that the names are simply the class name “decorated” together with the function name, so the internal names the compiler uses might be _f and _X_f . However, it turns out that function name decoration involves more than the class name. Here’s why. Suppose you want to overload two function names void print(char); void print(float); It doesn’t matter whether they are both inside a class or at the global scope. The compiler can’t generate unique internal identifiers if it uses only the scope of the function names. You’d end up with _print in both cases. The idea of an overloaded function is that you use the same function name, but different argument lists. Thus, for overloading to work the compiler must decorate the function name with the names of the argument types. The functions above, defined at global scope, produce internal names that might look something like _print_char and _print_float . It’s worth noting there is no standard for the way names must be decorated by the compiler, so you will see very different results from one compiler to another. (You can see what it looks like by telling the compiler to generate assembly-language output.) This, of course, causes problems if you want to buy compiled libraries for a particular compiler and linker – but even if name decoration were standardized, there would be other roadblocks because of the way different compilers generate code. That’s really all there is to function overloading: you can use the same function name for different functions as long as the argument lists are different. The compiler decorates the name, the scope, and 7: Function Overloading & Default Arguments 331 the argument lists to produce internal names for it and the linker to use. Overloading on return values It’s common to wonder, “Why just scopes and argument lists? Why not return values?” It seems at first that it would make sense to also decorate the return value with the internal function name. Then you could overload on return values, as well: void f(); int f(); This works fine when the compiler can unequivocally determine the meaning from the context, as in int x = f( ); . However, in C you’ve always been able to call a function and ignore the return value (that is, you can call the function for its side effects ). How can the compiler distinguish which call is meant in this case? Possibly worse is the difficulty the reader has in knowing which function call is meant. Overloading solely on return value is a bit too subtle, and thus isn’t allowed in C++. Type-safe linkage There is an added benefit to all of this name decoration. A particularly sticky problem in C occurs when the client programmer misdeclares a function, or, worse, a function is called without declaring it first, and the compiler infers the function declaration from the way it is called. Sometimes this function declaration is correct, but when it isn’t, it can be a difficult bug to find. Because all functions must be declared before they are used in C++, the opportunity for this problem to pop up is greatly diminished. The C++ compiler refuses to declare a function automatically for you, so it’s likely that you will include the appropriate header file. However, if for some reason you still manage to misdeclare a function, either by declaring by hand or including the wrong 332 Thinking in C++ www.BruceEckel.com header file (perhaps one that is out of date), the name decoration provides a safety net that is often referred to as type-safe linkage . Consider the following scenario. In one file is the definition for a function: //: C07:Def.cpp {O} // Function definition void f(int) {} ///:~ In the second file, the function is misdeclared and then called: //: C07:Use.cpp //{L} Def // Function misdeclaration void f(char); int main() { //! f(1); // Causes a linker error } ///:~ Even though you can see that the function is actually f(int) , the compiler doesn’t know this because it was told – through an explicit declaration – that the function is f(char) . Thus, the compilation is successful. In C, the linker would also be successful, but not in C++. Because the compiler decorates the names, the definition becomes something like f_int , whereas the use of the function is f_char . When the linker tries to resolve the reference to f_char , it can only find f_int , and it gives you an error message. This is type-safe linkage. Although the problem doesn’t occur all that often, when it does it can be incredibly difficult to find, especially in a large project. This is one of the cases where you can easily find a difficult error in a C program simply by running it through the C++ compiler. 7: Function Overloading & Default Arguments 333 Overloading example We can now modify earlier examples to use function overloading. As stated before, an immediately useful place for overloading is in constructors. You can see this in the following version of the Stash class: //: C07:Stash3.h // Function overloading #ifndef STASH3_H #define STASH3_H class Stash { int size; // Size of each space int quantity; // Number of storage spaces int next; // Next empty space // Dynamically allocated array of bytes: unsigned char* storage; void inflate(int increase); public: Stash(int size); // Zero quantity Stash(int size, int initQuantity); ~Stash(); int add(void* element); void* fetch(int index); int count(); }; #endif // STASH3_H ///:~ The first Stash( ) constructor is the same as before, but the second one has a Quantity argument to indicate the initial number of storage places to be allocated. In the definition, you can see that the internal value of quantity is set to zero, along with the storage pointer. In the second constructor, the call to inflate(initQuantity) increases quantity to the allocated size: //: C07:Stash3.cpp {O} // Function overloading #include "Stash3.h" #include " /require.h" #include <iostream> #include <cassert> 334 Thinking in C++ www.BruceEckel.com using namespace std; const int increment = 100; Stash::Stash(int sz) { size = sz; quantity = 0; next = 0; storage = 0; } Stash::Stash(int sz, int initQuantity) { size = sz; quantity = 0; next = 0; storage = 0; inflate(initQuantity); } Stash::~Stash() { if(storage != 0) { cout << "freeing storage" << endl; delete []storage; } } int Stash::add(void* element) { if(next >= quantity) // Enough space left? inflate(increment); // Copy element into storage, // starting at next empty space: int startBytes = next * size; unsigned char* e = (unsigned char*)element; for(int i = 0; i < size; i++) storage[startBytes + i] = e[i]; next++; return(next - 1); // Index number } void* Stash::fetch(int index) { require(0 <= index, "Stash::fetch (-)index"); if(index >= next) return 0; // To indicate the end // Produce pointer to desired element: return &(storage[index * size]); } 7: Function Overloading & Default Arguments 335 int Stash::count() { return next; // Number of elements in CStash } void Stash::inflate(int increase) { assert(increase >= 0); if(increase == 0) return; int newQuantity = quantity + increase; int newBytes = newQuantity * size; int oldBytes = quantity * size; unsigned char* b = new unsigned char[newBytes]; for(int i = 0; i < oldBytes; i++) b[i] = storage[i]; // Copy old to new delete [](storage); // Release old storage storage = b; // Point to new memory quantity = newQuantity; // Adjust the size } ///:~ When you use the first constructor no memory is allocated for storage . The allocation happens the first time you try to add( ) an object and any time the current block of memory is exceeded inside add( ) . Both constructors are exercised in the test program: //: C07:Stash3Test.cpp //{L} Stash3 // Function overloading #include "Stash3.h" #include " /require.h" #include <fstream> #include <iostream> #include <string> using namespace std; int main() { Stash intStash(sizeof(int)); for(int i = 0; i < 100; i++) intStash.add(&i); for(int j = 0; j < intStash.count(); j++) cout << "intStash.fetch(" << j << ") = " << *(int*)intStash.fetch(j) << endl; 336 Thinking in C++ www.BruceEckel.com const int bufsize = 80; Stash stringStash(sizeof(char) * bufsize, 100); ifstream in("Stash3Test.cpp"); assure(in, "Stash3Test.cpp"); string line; while(getline(in, line)) stringStash.add((char*)line.c_str()); int k = 0; char* cp; while((cp = (char*)stringStash.fetch(k++))!=0) cout << "stringStash.fetch(" << k << ") = " << cp << endl; } ///:~ The constructor call for stringStash uses a second argument; presumably you know something special about the specific problem you’re solving that allows you to choose an initial size for the Stash . unions As you’ve seen, the only difference between struct and class in C++ is that struct defaults to public and class defaults to private . A struct can also have constructors and destructors, as you might expect. But it turns out that a union can also have a constructor, destructor, member functions, and even access control. You can again see the use and benefit of overloading in the following example: //: C07:UnionClass.cpp // Unions with constructors and member functions #include<iostream> using namespace std; union U { private: // Access control too! int i; float f; public: U(int a); U(float b); 7: Function Overloading & Default Arguments 337 ~U(); int read_int(); float read_float(); }; U::U(int a) { i = a; } U::U(float b) { f = b;} U::~U() { cout << "U::~U()\n"; } int U::read_int() { return i; } float U::read_float() { return f; } int main() { U X(12), Y(1.9F); cout << X.read_int() << endl; cout << Y.read_float() << endl; } ///:~ You might think from the code above that the only difference between a union and a class is the way the data is stored (that is, the int and float are overlaid on the same piece of storage). However, a union cannot be used as a base class during inheritance, which is quite limiting from an object-oriented design standpoint (you’ll learn about inheritance in Chapter 14). Although the member functions civilize access to the union somewhat, there is still no way to prevent the client programmer from selecting the wrong element type once the union is initialized. In the example above, you could say X.read_float( ) even though it is inappropriate. However, a “safe” union can be encapsulated in a class. In the following example, notice how the enum clarifies the code, and how overloading comes in handy with the constructors: //: C07:SuperVar.cpp // A super-variable #include <iostream> using namespace std; class SuperVar { 338 Thinking in C++ www.BruceEckel.com enum { character, integer, floating_point } vartype; // Define one union { // Anonymous union char c; int i; float f; }; public: SuperVar(char ch); SuperVar(int ii); SuperVar(float ff); void print(); }; SuperVar::SuperVar(char ch) { vartype = character; c = ch; } SuperVar::SuperVar(int ii) { vartype = integer; i = ii; } SuperVar::SuperVar(float ff) { vartype = floating_point; f = ff; } void SuperVar::print() { switch (vartype) { case character: cout << "character: " << c << endl; break; case integer: cout << "integer: " << i << endl; break; case floating_point: cout << "float: " << f << endl; break; } } 7: Function Overloading & Default Arguments 339 int main() { SuperVar A('c'), B(12), C(1.44F); A.print(); B.print(); C.print(); } ///:~ In the code above, the enum has no type name (it is an untagged enumeration). This is acceptable if you are going to immediately define instances of the enum , as is done here. There is no need to refer to the enum’s type name in the future, so the type name is optional. The union has no type name and no variable name. This is called an anonymous union , and creates space for the union but doesn’t require accessing the union elements with a variable name and the dot operator. For instance, if your anonymous union is: //: C07:AnonymousUnion.cpp int main() { union { int i; float f; }; // Access members without using qualifiers: i = 12; f = 1.22; } ///:~ Note that you access members of an anonymous union just as if they were ordinary variables. The only difference is that both variables occupy the same space. If the anonymous union is at file scope (outside all functions and classes) then it must be declared static so it has internal linkage. Although SuperVar is now safe, its usefulness is a bit dubious because the reason for using a union in the first place is to save space, and the addition of vartype takes up quite a bit of space relative to the data in the union , so the savings are effectively [...]... decide which is clearer for your particular coding style Here are the above lines in a compileable file: //: C0 8:ConstPointers.cpp const int* u; int const* v; int d = 1; int* const w = &d; const int* const x = &d; // (1) int const* const x2 = &d; // (2) int main() {} ///:~ 362 Thinking in C+ + www.BruceEckel.com Formatting This book makes a point of only putting one pointer definition on a line, and initializing... that moves the stack pointer to accommodate the array In both of the illegal definitions above, the compiler complains because it cannot find a constant expression in the array definition Differences with C Constants were introduced in early versions of C+ + while the Standard C specification was still being finished Although the C committee then decided to include const in C, somehow it came to mean for... safety #include using namespace std; const int i = 100; // Typical constant const int j = i + 10; // Value from const expr long address = (long)&j; // Forces storage char buf[j + 10]; // Still a const expression int main() { cout . "Stash3.h" #include " /require.h" #include <iostream> #include <cassert> 334 Thinking in C+ + www.BruceEckel.com using namespace std; const int increment = 100; . Here’s the implementation of the class: //: C0 7:Mem.cpp {O} 344 Thinking in C+ + www.BruceEckel.com #include "Mem.h" #include <cstring> using namespace std; Mem::Mem() { mem. arguments in the function definition, for documentation purposes void fn(int x /* = 0 */) { // 342 Thinking in C+ + www.BruceEckel.com Placeholder arguments Arguments in a function declaration can