|
| C++ dlopen HOWTO | |
| This document is about dynamical loading of C++ functions and classes using the dlopen API | |
|
| |
| C-C++ Beautifier | |
| This document will help you to format (beautify) the C/C++ programs so that it is more readable and confirms to your site C/C++ coding stan dards. The information in this document applies to all the operating sytems that is - Linux, MS DOS, Apple Macintosh, Windows 95/NT/2000, BeOS, OS/2, IBM OSes, all flavors of Unix like Solaris, HPUX, AIX, SCO, Sinix, BSD, UnixWare, etc.. and to all other operating systems which support "C" compiler | |
|
| |
| C++ Programming HOW-TO | |
| This document provides a comprehensive list of C++ URL pointers, links to C++ online textbooks, and programming tips on C++. This document also provides a C++ library which imitates Java-language, and which has various methods to avoid memory problems in C++. Using this library you can compile Java's source code under C++. This document serves as a "Home of C++ language". | |
|
| |
| while | |
| while, do-while, and for control looping. A statement repeats until the controlling expression evaluates to false. | |
|
| |
| Under the hood | |
| It can be helpful to see the assembly-language code generated by a virtual function call, so you can see that late-binding is indeed taking place. | |
|
| |
| Template syntax | |
| The template keyword tells the compiler that the class definition that follows will manipulate one or more unspecified types. At the time the actual class code is generated from the template, those types must be specified so that the compiler can substitute them. | |
|
| |
| Constants in templates | |
| Template arguments are not restricted to class types; you can also use built-in types. The values of these arguments then become compile-time constants for that particular instantiation of the template. You can even use default values for these arguments. | |
|
| |
| Holding objects by value | |
| The copy constructor for the contained objects does most of the work by passing and returning the objects by value. Inside push( ), storage of the object onto the Stack array is accomplished with T::operator=. | |
|
| |
| Pure virtual definitions | |
| It’s possible to provide a definition for a pure virtual function in the base class. You’re still telling the compiler not to allow objects of that abstract base class, and the pure virtual functions must still be defined in derived classes in order to create objects. | |
|
| |
| Extensibility | |
| With play( ) defined as virtual in the base class, you can add as many new types as you want without changing the tune( ) function. In a well-designed OOP program, most or all of your functions will follow the model of tune( ) and communicate only with the base-class interface. Such a program is extensible because you can add new functionality by inheriting new data types from the common base class. | |
|
| |
| Creating an object-based hierarchy | |
| An issue that has been recurring throughout this book during the demonstration of the container classes Stack and Stash is the “ownership problem.” The “owner” refers to who or what is responsible for calling delete for objects that have been created dynamically (using new). The problem when using containers is that they need to be flexible enough to hold different types of objects. | |
|
| |
| Turning ownership on and off | |
| Let’s return to the ownership problem. Containers that hold objects by value don’t usually worry about ownership because they clearly own the objects they contain. But if your container holds pointers (which is more common with C++, especially with polymorphism), then it’s very likely those pointers may also be used somewhere else in the program, and you don’t necessarily want to delete the object because then the other pointers in the program would be referencing a destroyed object. | |
|
| |
| Operator overloading | |
| You can make operators virtual just like other member functions. Implementing virtual operators often becomes confusing, however, because you may be operating on two objects, both with unknown types. This is usually the case with mathematical components (for which you often overload operators). | |
|
| |
| Objects are different | |
| It’s important to realize that upcasting deals only with addresses. If the compiler has an object, it knows the exact type and therefore (in C++) will not use late binding for any function calls – or at least, the compiler doesn’t need to use late binding. | |
|
| |
| Virtuals in destructors | |
| There’s something that happens during destruction that you might not immediately expect. If you’re inside an ordinary member function and you call a virtual function, that function is called using the late-binding mechanism. This is not true with destructors, virtual or not. | |
|
| |
| Stack with iterators | |
| We can repeat the process with the dynamically-sized Stack class that has been used as an example throughout the book. | |
|
| |
| Non-inline function definitions | |
| Of course, there are times when you’ll want to have non-inline member function definitions. In this case, the compiler needs to see the template declaration before the member function definition. | |
|
| |
| Variant return type | |
| The Derived3 class above suggests that you cannot modify the return type of a virtual function during overriding. This is generally true, but there is a special case in which you can slightly modify the return type. If you’re returning a pointer or a reference to a base class, then the overridden version of the function may return a pointer or reference to a class derived from what the base returns. | |
|
| |
| PStash with iterators | |
| For most container classes it makes sense to have an iterator. | |
|
| |
