Welcome to 876 Softwares, the home of programming languages.

Q&A Part IV

May 07 2008 at 9:23 am  130

Q. Must a string class use a char * to hold the contents of the string?

A. No. It can use any memory storage the designer thinks is best.

Q. Are inherited members and functions passed along to subsequent generations? If Dog derives from Mammal, and Mammal derives from Animal, does Dog inherit Animal′s functions and data?

A. Yes. As derivation continues, derived classes inherit the sum of all the functions and data in all their base classes.

Q. If, in the example above, Mammal overrides a function in Animal, which does Dog get, the original or the overridden function?

A. If Dog inherits from Mammal, it gets the function in the state Mammal has it: the overridden function.

Q. Can a derived class make a public base function private?

A. Yes, and it remains private for all subsequent derivation.

Q. Why not make all class functions virtual?

A. There is overhead with the first virtual function in the creation of a v-table. After that, the overhead is trivial. Many C++ programmers feel that if one function is virtual, all others should be. Other programmers disagree, feeling that there should always be a reason for what you do.

Q. If a function (SomeFunc()) is virtual in a base class and is also overloaded, so as to take either an integer or two integers, and the derived class overrides the form taking one integer, what is called when a pointer to a derived object calls the two-integer form?

A. The overriding of the one-int form hides the entire base class function, and thus you will get a compile error complaining that that function requires only one int.

Q. What does percolating functionality upwards mean?

A. This refers to the idea of moving shared functionality upwards into a common base class. If more than one class shares a function, it is desirable to find a common base class in which that function can be stored.

Q. Is percolating upwards always a good thing?

A. Yes, if you are percolating shared functionality upwards. No, if all you are moving is interface. That is, if all the derived classes can′t use the method, it is a mistake to move it up into a common base class. If you do, you′ll have to switch on the runtime type of the object before deciding if you can invoke the function.

Q. Why is switching on the runtime type of an object bad?

A. With large programs, the switch statements become big and hard to maintain. The point of virtual functions is to let the virtual table, rather than the programmer, determine the runtime type of the object.

Q. Why is casting bad?

A. Casting isn′t bad if it is done in a way that is type-safe. If a function is called that knows that the object must be of a particular type, casting to that type is fine. Casting can be used to undermine the strong type checking in C++, and that is what you want to avoid. If you are switching on the runtime type of the object and then casting a pointer, that may be a warning sign that something is wrong with your design.

Q. Why not make all functions virtual?

A. Virtual functions are supported by a virtual function table, which incurs runtime overhead, both in the size of the program and in the performance of the program. If you have very small classes that you don′t expect to subclass, you may not want to make any of the functions virtual.

Q. When should the destructor be made virtual?

A. Anytime you think the class will be subclassed, and a pointer to the base class will be used to access an object of the subclass. As a general rule of thumb, if you′ve made any functions in your class virtual, be sure to make the destructor virtual as well.

Q. Why bother making an Abstract Data Type--why not just make it non-abstract and avoid creating any objects of that type?

A. The purpose of many of the conventions in C++ is to enlist the compiler in finding bugs, so as to avoid runtime bugs in code that you give your customers. Making a class abstract, that is, giving it pure virtual functions causes the compiler to flag any objects created of that abstract type as errors.

Q. Why use static data when you can use global data?

A. Static data is scoped to the class. In this manner, static data are available only through an object of the class, through an explicit call using the class name if they are public, or by using a static member function. Static data are typed to the class type, however, and the restricted access and strong typing makes static data safer than global data.

Q. Why use static member functions when you can use global functions?

A. Static member functions are scoped to the class, and can be called only by using an object of the class or an explicit full specification (such as ClassName::FunctionName()).

Q. Is it common to use many pointers to functions and pointers to member functions?

A. No, these have their special uses, but are not common constructs. Many complex and powerful programs have neither.

Posted by administrator | Categories: C++ | Comments: 73