Phew, a lot has happened since my last post on this subject. After much wrangling with the C preprocessor I have a working pattern which I'm mostly happy with. It currently includes support for the following...
- Classes
- Private data
- Public methods
- Private methods
- Multiple interfaces
- A unit test framework
- Some eclipse file templates
Still to do (in no particular order)...
- Documentation
- Performance profiling
- Exception handling
- Improve unit test automation
- Eclipse wizards
Things that I'm not quite sure about...
- Not sure if I really needed to implement the unit test stuff as classes and interfaces but it has an elegance
- Don't much like having multiple calling conventions for public methods, private methods and interface methods
- No support for inheritance - is it really needed anyway?
- No support for up casting and figuring out what type something is at run time - this may become more of an issue when thinking about exception handling
- Currently only support a single constructor
This state can be found on GitHub here
So how does it look right now (after all there is no documentation ;))
Create an application that runs unit tests
After generating your own application as described in OOOCode - Part 1 copy in the OOOCode/src/OOOCode directory from the above github project and add it and its subdirectories to the OpenTV options include paths.
Then create a Main.c as below...
The above code achieves the following...
- Records the memory available at start up
-
Creates a debug output object using the OOOConstruct macro
- In this case an OOODebug class is used instead of direct calls to O_debug as in tests for the unit test classes themselves it is necessary to use mock objects
- Creates a debug reporter object
- Unit test reports need to go somewhere, this class dumps them to debug output
- The debug instance is cast to an IDebug interface using the OOOCast macro, in this way it is possible to pass in a mock object when needed
- Calls the OOOUnitTestsRun method passing in the reporter to run the tests
- The debug reporter is cast to an IReporter interface using the OOOCast macro, this will allow the unit test framework to be extended later with different reporter objects (eg. over HTTP, etc)
- Then the instantiated objects are destroyed using the OOODestroy macro and the memory is checked to ensure that the tests and the unit test framework used did not leak
- The last part (while loop) just ensures that the VSTB does not exit so we can see the test report in the debug output
So there are some key concepts introduced here...
- OOOConstruct - use this to construct an instance of a class, the first parameter is the class name, additional parameters are passed into the constructor as arguments
- OOOCast - use this to cast an instance of a class to an interface, the first parameter is the interface name, the second parameter is the class instance
- OOODestroy - use this to destroy an instance of a class and free it's memory, the only argument is the class instance
However, this will not yet compile. The function OOOUnitTestsRun is a special function that is generated by the OOOUnitTestsRun.h header file using xmacros. It generates an array of tests to run and runs them based on the contents of another header file: OOOTests.h
This initial OOOTests.h is empty and so this application does not yet run any tests. Now the application can be compiled (assuming that the OOOCode source has been added to the include paths).
NB. The OOOTests.h file does not have an include guard and this is deliberate. An include guard would prevent the xmacros that use it from working. For more details on the xmacro pattern see this drdobbs article
Adding a test for MyClass
First update OOOTests.h...
Once again this will not compile, but hey, we're doing test driven development.
Add the MyClass.Test.h header...
Still this will not compile, but note that the OOOTest macro call does not have a semicolon on the end - this is important. This just declares the test it does not yet compile because the test has not been implemented. Other tests can be declared with other names by adding further OOOTest calls (without semicolons)
Add the MyClass.Test.c file...
Now it gets a little bit more interesting and in fact should compile and run again. When it is run this code will print the "MyClass test" string to the debug in an xml test report format signifying that it is just information. The important concepts that we now have are...
- Declare tests with calls to OOOTest in unguarded headers that are included in OOOTests.h
- Implement tests using the OOOTest macro as defined in OOOUnitTestDefines.h so that they look like functions
-
We can ouput information to the test report using the OOOInfo macro (this is actually a variadic macro that behaves like printf). Two other similar macros are also available in test implementations...
- OOOWarning - adds a warning to the test report
- OOOError - adds an error to the test report
Adding MyClass
We are going to add a class that takes an integer in the constructor and exports a method to retrieve that integer. So lets first write some more of the test. We update MyClass.Test.c as follows...
Again this will not compile but we can see how we want our class to behave...
- We include the class header (does not yet exist)
- We construct an instance of the class
- We check the retrieval of the integer constructor parameter
- We destroy the instance of the class
The key concepts are...
- The memory allocated in a test must be freed in the test, the unit test framework does check for memory anomalies and adds them to the test report
- Public methods are called with the OOOCall macro, the first argument is the instance, the second argument is the method name, additional arguments would be the parameters for the method
- OOOCheck is used to test a condition that must be true for the test to pass, it can be called as many times as you like but if the condition resolves to FALSE then an error entry will be added to the test report along with the file, line and condition that failed, etc.
Add MyClass.h...
Now things are getting really interesting. Still this will not compile as we do not have an implementation for MyClass but lets go through what's happening here in the header...
- We have an include guard - that's fine here :)
- The OOCode.h header is included to enable all the OOOCode goodness ;)
- The name of the class is #defined as OOOClass - this is used inside other macros as the class name and simplifies those macro calls
- The class is declared using the OOODeclare macro, it takes the constructor arguments as parameters
- A list of implemented interfaces is given using the OOOImplements block, this must be present even if it is empty as in this case
- A list of public methods is given using the OOOExports block, in this case one method is exported using OOOExport
- The declare block is closed and importantly OOOClass is #undef'd so that other classes can be declared
Let's go through those macro calls in a bit more detail...
- OOODeclare - actually declares the type and the constructor hence the addition of the constructor arguments
- OOOImplements - starts the structure defining the public interfaces avialable (OOOImplement will be detailed later)
- OOOImplement - finalizes the interfaces structure
- OOOExports - starts the vtable structure providing access to public methods
- OOOExport - adds a public method to the vtable, the first argument is the return type, the second argument is the name of the method, any further arguments will be the parameters for the method (in this case there are none)
- OOOExportsEnd - finalizes the vtable structure
- OOODeclareEnd - this finalizes everything and defines a public structure used to access the public methods and interfaces
Now we're also ready to add the implementation, so create the following MyClass.c file...
So what's this all about then...
- Include the MyClass.h header
- #define OOOClass to the name of the class, again this is so that other macro calls can use it and their interfaces are thus simplified (it would be nice if macros could define other macros internally, but hey ho...)
- Declare the private data fields using OOOPrivateData - just one integer field
- Implement the destructor function with OOODestructor - in this case it is empty as no additional memory is allocated when constructing objects of this class
- Implement a method using OOOMethod - this one just returns the integer field accessed through a call to the OOOF macro
- Implement the constructor using OOOConstructor - in the constructor it is also necessary to map any internal functions to external methods and interfaces, in this case...
- OOOMapMethods is used to open a list methods to map to the exported vtable
- OOOMethodMapping is used to map the getMyField method to the first entry in the vtable - the compiler will pick up any type incompatibilities here
- The mapping is closed with OOOMapMethodsEnd
- Lastly the constructor assigns the nMyField parameter to the nMyField private data entry (again using the OOOF accessor macro)
Again let's look at these new macros...
- OOOPrivateData - starts a new private data structure, this should only appear once
- OOOPrivateDataEnd - closes the private data structure, fields in the structure should be placed between these 2 macros in the same format you would use for a struct (it is a struct!)
- OOODestructor - this starts the destructor method, destructors take no additional arguments, this should only appear once
- OOODestructorEnd - this ends the destructor method, it actually also frees the class instance which is why you don't have to do it yourself. The curly braces between these 2 macro calls in this case a re purely a matter of style and optional, they would only be required if it were necessary to declare any local variables in the destructor method. I use them anyway because it makes the implementation look more like a standard C method (a bit)
- OOOMethod - this starts a method implementation, the first argument is the return type, the second is the method name, any additional arguments will be passed into the method. The method is effectively private until it is mapped to the class or an interface vtable (the macro declares it static)
- OOOMethodEnd - this closes the method implementation, again the curly braces are mostly optional
- OOOConstructor - this starts the constructor implementation, it should appear only once. The arguments are the constructor parameters
- OOOMapMethods - this starts the class vtable mapping
- OOOMethodMapping - this maps a method to an entry in the class vtable, the only parameter is the method name - this is the private method name as defined in the call to OOOMethod, it does not have to match the exported method name in the vtable defined in the header. It is important to add the methods to the mapping in the same order that they are added to the vtable in the header using calls to OOOExport
- OOOMapMethodsEnd - this closes the vtable mapping
- OOOConstructorEnd - this closes the constructor implementation
- OOOF - this macro accesses the private fields of the current class instance, the only argument is the name of the field. It is not possible to access fields of instances of other classes but later we will see how to access fields of other instances of the same class
Adding IMyInterface
We will now add an interface that defines a single method that returns an integer. Again let's start with the test and update MyClass.Test.c as follows...
Only a small change but again this will not compile...
- We added a new check, casting the instance to IMyInterface and calling the getData interface method using the OOOICall calling convention - in the test I have assumed that getData will be mapped to retrieving the constructor parameter
Only one new macro has been introduced here...
- OOOICall - this macro must be used when calling methods on interface instances, it is much the same as OOOCall in that the first argument is the interface instance, the second argument is the interface method name and any additional arguments are passed through as parameters to the implementation
To make this compile we will have to add IMyInterface.h and update MyClass to implement the interface...
This is pretty similar to the pattern used to declare the class...
- There is an include guard
- OOOCode.h is included
- This time we specify the interface name in a #define called OOOInterface
- The interface vtable is then started with a call to the OOOVirtuals macro
- Methods are added to the vtable using calls to the OOOVirtual macro
- The vtable is then closed and OOOInterface is #undef'd so that other interfaces can be declared
So the new macros are...
- OOOVirtuals - starts the interface vtable
- OOOVirtual - declares a method entry in the vtable, the first argument will be the return type, the second argument is the method name and any additional arguments will be the parameters for the method. Any method implementing this virtual method will have to have the same signature and the compiler will check
- OOOVirtualsEnd - closes the interface vtable
This still won't compile so next we update MyClass.h...
Again a small change...
- The interface header has been added
- An OOOImplement call has been added to the OOOImplements block to add the interface to the declaration
Just one new macro then...
- OOOImplement - this adds the interface to the interface table, the only argument is the name of the interface
This will compile but the test will fail. In fact the test should crash with a NULL pointer exception as the method has neither been implemented or mapped to the interface. We need to update MyClass.c too...
Now the code will both compile and the tests will run successfully! (assuming I transcribed everything correctly).
There are 2 additions here...
- The method has been implemented as getData and this method just calls the other method using the private method calling convention, OOOC
-
The interface vtable has been mapped in the constructor
- The interface name is given in the OOOInterface #define to simplify the other macro calls
- The interface vtable mapping is started with a call to OOOMapVirtuals
- The getData method is mapped using a call to the OOOVirtualMapping macro
- The mapping is closed with a call to OOOMapVirtualsEnd and OOOInterface is undef'd so that other interfaces can be mapped
So the new macros we have used are...
- OOOC - this macro accesses the private methods of the current class instance, the first argument is the name of the method and any additional arguments are passed through as parameters to the method. It is not possible to access private methods of instances of other classes but later we will see how to access methods of other instances of the same class
- OOOMapVirtuals - this starts the interface vtable mapping
- OOOVirtualMapping - this maps a method to an entry in the interface vtable, the only parameter is the method name - this is the private method name as defined in the call to OOOMethod, it does not have to match the exported method name in the vtable defined in the interface header. It is important to add the methods to the mapping in the same order that they are added to the vtable in the interface header using calls to OOOVirtual
- OOOMapVirtualsEnd - this closes the interface vtable mapping
Adding copy and isEqual methods
As a final example and to round out the macro examples let's see how we can add additional methods to copy and compare instances of MyClass. Of course, we start with a test so let's update MyClass.Test.c...
The following changes were made...
- A new instance of MyClass, pMyClassCopy, is generated through a call to a new copy method
- We check that the new copy is equal to the original
- We check that the new copy returns the same value from getMyField
- We check that the copy method didn't cheat and that the copy is a different instance (pointer address)
- We remember to clean up the new instance too
Once again our code does not compile, but that's ok. We need to update MyClass.h to export the new methods...
This will now compile but, as with the interface implementation, the test will crash when it gets to the copy call as the method has not been implemented and mapped in the vtable. Anyway let's see what we've done...
- Two new calls have been made to OOOExport to export the copy and isEqual methods
Now we implement and map the methods in MyClass.c...
Yay, sucess! The code compiles, runs and the tests pass. We added 2 new methods and mapped them so what's new in this...
- In the compare method we used a new macro, OOOPCall, this is more efficient than OOOCall and can also be used to access unmapped methods in a class. The first argument is the class instance, the second is the method name and any additional arguments will be passed into the method. In this case OOOC could not be used as we wanted to call a method on another instance
- Notice that the additional mappings in OOOMapMethods are preceded by commas - this is because they result in static initialiser elements in a structure. The same applied to the virtual mappings if there are more than one.
So what haven't we seen? Well, two additional things spring to mind...
- It is also possible to access fields on other instances of a class. This is achieved through calls to OOOField, like OOOPCall this can only be used in the class implementation and the first parameter will be the instance, the second parameter is the field name. We could have used this in place of OOOPCall above but it is a matter of style to use the accessor method instead (performance optimisations could dictate otherwise though)
- If it is necessary to access the current instance (perhaps to return from a method or pass into another method) then it is always available in the methods, constructor and destructor through the OOOThis pointer
So that's it. Although this will all probably change in the next 5 minutes. If you're interested then keep an eye on this blog and the GitHub repository.
