Find unimplemented class methods - c++

Question

In my application, I'm dealing with a larger-size classes (over 50 methods) each of which is reasonably complex. I'm not worried about the complexity as they are still straight forward in terms of isolating pieces of functionality into smaller methods and then calling them. This is how the number of methods becomes large (a lot of these methods are private - specifically isolating pieces of functionality).
However when I get to the implementation stage, I find that I loose track of which methods have been implemented and which ones have not been. Then at linking stage I receive errors for the unimplemented methods. This would be fine, but there are a lot of interdependencies between classes and in order to link the app I would need to get EVERYTHING ready. Yet I would prefer to get one class our of the way before moving to the next one.
For reasons beyond my control, I cannot use an IDE - only a plain text editor and g++ compiler. Is there any way to find unimplemented methods in one class without doing a full linking? Right now I literally do text search on method signatures in the implementation cpp file for each of the methods, but this is very time consuming.

Answer 1

You could add a stub for every method you intend to implement, and do:
void SomeClass::someMethod() {
#error Not implemented
}
With gcc, this outputs file, line number and the error message for each of these. So you could then just compile the module in question and grep for "Not implemented", without requiring a linker run.
Although you then still need to add these stubs to the implementation files, which might be part of what you were trying to circumvent in the first place.

Answer 2

Though I can't see a simple way of doing this without actually attempting to link, you could grep the linker output for "undefined reference to ClassInQuestion::", which should give you only lines related to this error for methods of the given class.
This at least lets you avoid sifting through all error messages from the whole linking process, though it does not prevent having to go through a full linking.

Answer 3

That’s what unit tests and test coverage tools are for: write minimal tests for all functions up-front. Tests for missing functions won’t link. The test coverage report will tell you whether all functions have been visited.
Of course that’s only helping up to some extent, it’s not a 100% fool proof. Your development methodology sounds slightly dodgy to me though: developing classes one by one in isolation doesn’t work in practice: classes that depend on each other (and remember: reduce dependencies!) need to be developed in lockstep to some extent. You cannot churn out a complete implementation for one class and move to the next, never looking back.

Answer 4

In the past I have built an executable for each class:
#include "klass.h"
int main() {
Klass object;
return 0;
}
This reduces build time, can let you focus on one class at a time, speeds up your feedback loop.
It can be easily automated.
I really would look at reducing the size of that class though!
edit
If there are hurdles, you can go brute force:
#include "klass.h"
Klass createObject() {
return *reinterpret_cast<Klass>(0);
}
int main() {
Klass object = createObject();
return 0;
}

Answer 5

You could write a small script which analyses the header file for method implementations (regular expressions will make this very straightforward), then scans the implementation file for those same method implementations.
For example in Ruby (for a C++ compilation unit):
className = "" # Either hard-code or Regex /class \w+/
allMethods = []
# Scan header file for methods
File.open(<headerFile>, "r") do |file|
allLines = file.map { |line| line }
allLines.each do |line|
if (line =~ /(\);)$/) # Finds lines ending in ");" (end of method decl.)
allMethods << line.strip!
end
end
end
implementedMethods = []
yetToImplement = []
# Scan implementation file for same methods
File.open(<implementationFile>, "r") do |file|
contents = file.read
allMethods.each do |method|
if (contents.include?(method)) # Or (className + "::" + method)
implementedMethods << method
else
yetToImplement << method
end
end
end
# Print the results (may need to scroll the code window)
print "Yet to implement:\n"
yetToImplement.each do |method|
print (method + "\n")
end
print "\nAlready implemented:\n"
implementedMethods.each do |method
print (method + "\n")
end
Someone else will be able to tell you how to automate this into the build process, but this is one way to quickly check which methods haven't yet been implemented.

Answer 6

The delete keyword of c++11 does the trick
struct S{
void f()=delete; //unimplemented
};
If C++11 is not avaiable, you can use private as a workaround
struct S{
private: //unimplemented
void f();
};
With this two method, you can write some testing code in a .cpp file
//test_S.cpp
#include "S.hpp"
namespace{
void test(){
S* s;
s->f(); //will trigger a compilation error
}
}
Note that your testing code will never be executed. The namespace{} says to the linker that this code is never used outside the current compilation unit (i.e., test_S.cpp) and will therefore be dropped just after compilation checking.
Because this code is never executed, you do not actualy need to create a real S object in the test function. You just want to trick the compiler in order to test if a S objects has a callable f() function.

Answer 7

You can create a custom exception and throw it so that:
Calling an unimplemented function will terminate the application instead of leaving it in an unexpected state
The code can still be compiled, even without the required functions being implemented
You can easily find the unimplemented functions by looking through compiler warnings (by using some possibly nasty tricks), or by searching your project directory
You can optionally remove the exception from release builds, which would cause build errors if there are any functions that try to throw the exception
#if defined(DEBUG)
#if defined(__GNUC__)
#define DEPRECATED(f, m) f __attribute__((deprecated(m)))
#elif defined(_MSC_VER)
#define DEPRECATED(f, m) __declspec(deprecated(m)) f
#else
#define DEPRECATED(f, m) f
#endif
class not_implemented : public std::logic_error {
public:
DEPRECATED(not_implemented(), "\nUnimplemented function") : logic_error("Not implemented.") { }
}
#endif // DEBUG
Unimplemented functions would look like this:
void doComplexTask() {
throw not_implemented();
}
You can look for these unimplemented functions in multiple ways. In GCC, the output for debug builds is:
main.cpp: In function ‘void doComplexTask()’:
main.cpp:21:27: warning: ‘not_implemented::not_implemented()’ is deprecated:
Unimplemented function [-Wdeprecated-declarations]
throw not_implemented();
^
main.cpp:15:16: note: declared here
DEPRECATED(not_implemented(), "\nUnimplemented function") : logic_error("Not implemented.") { }
^~~~~~~~~~~~~~~
main.cpp:6:26: note: in definition of macro ‘DEPRECATED’
#define DEPRECATED(f, m) f __attribute__((deprecated(m)))
Release builds:
main.cpp: In function ‘void doComplexTask()’:
main.cpp:21:11: error: ‘not_implemented’ was not declared in this scope
throw not_implemented;
^~~~~~~~~~~~~~~
You can search for the exception with grep:
$ grep -Enr "\bthrow\s+not_implemented\b"
main.cpp:21: throw not_implemented();
The advantage of using grep is that grep doesn't care about your build configuration and will find everything regardless. You can also get rid of the deprecated qualifier to clean up your compiler output--the above hack generates a lot of irrelevant noise. Depending on your priorities this might be a disadvantage (for example, you might not care about Windows-specific functions if you're currently implementing Linux-specific functions, or vice-versa.)
If you use an IDE, most will let you search your entire project, and some even let you right-click a symbol and find everywhere it is used. (But you said you can't use one so in your case grep is your friend.)

Answer 8

I cannot see an easy way of doing this. Having several classes with no implementation will easily lead to a situation where keeping track in a multiple member team will be a nightmare.
Personally I would want to unit test each class I write and test driven development is my recommendation. However this involves linking the code each time you want to check the status.
For tools to use TDD refer to link here.
Another option is to write a piece of code that can parse through the source and check for functihat are to be implemented. GCC_XML is a good starting point.