CS 4448 - Spring 1998
Object-Oriented Programming and Design
Discussion 10.2.1
by
Steve Goss
Unreachable Procedures in Object-Oriented Programming
by
Amitabh Srivastava
- Agreed that the presence of unreachable procedures was an annoyance but certain points in the author's argument were a little shaky. His (short) paragraph on debugging said that code inserted to aid in debugging the program is unreachable because it is never called in the released program. This is not a very well formed argument. Any good programmer should always remove debugging statements before compiling the final release. Compilers also have options to add or remove extra information in the executable that can be used by debugging programs. Any extra code caused by these are the fault of the programmer(s) not the OO paradigm.
- Regarding the technique of finding unreachable procedures, it was noted that it appear to be very similar to the idea of garbage collection and that algorithms such as reference counting could be used as well. The only difficulty that occurs is when virtual functions are used and when they should be added to the graph.
- The percentage graphs that show programs compiled without system libraries show a high percentage of unreachable procedures in C++ (up to 26%) while c and FORTRAN have next to none. In the percentage graphs that show programs compiled with system libraries all of the percentages went up even the C and FORTRAN programs. One possibility for the large C++ percentages is that OO design lends itself to grouping similar objects together to form a type of library like system libraries. Large applications can have many of these user created libraries and when they are included, just like the system libraries, they increase the number of unreachable procedures.
- It was noticed that, as program size grows, the percentage of unreachable code dropped for C and FORTRAN while it rose for C++. One idea was that as C and FORTRAN programs grew in size and functionality, more procedures were added but they were only added to be used thus increasing the program size but not the number of unreachable procedures. In C++ it is possible to create new classes to add the new functionality but not all of the methods will necessarily be used.
- The authors proposed solution to the problem was another shaky area under our scrutiny. He suggested to add "a link-time option to process the program and remove all unreachable procedures". The lack of clarity on the implementation of this feature left most of us in the dark. The author's clam that this option works "without incurring any penalty" was also ambiguous. Did it mean that they structure of the program was left intact or that the entire process was penalty free. If the latter is the case, the author is mistaken. In order to remove the unused procedures, the linker would have to make another pass (probably more) over the program this could be very costly, in time, for large programs.
- Finally, it was mentioned that we would like to see some kind of run-time analysis graph or other medium to convince us that unused procedures are really the problem that the author makes them out to be.
Copyright © University of Colorado. All rights reserved.
Revised: March 31, 1998