C++ - putting the language elements together into a program
Archive - Originally posted on "The Horse's Mouth" - 2011-01-08 10:02:13 - Graham Ellis
On the final day of the C++ course yesterday, I demonstrated a number of advanced features and pulled together various strands that we had been learning through the week. At one level, each feature of the language can be explained and taught, but there's a further level that's need to show how they work together, and how they can best be made use of in combination.Within the Object Oriented design area, we started the day by writing a series of classes - a base class, several that inherit from it, and then a further subclass of a subclass, and creating an array of the various types - see [here]. The base class is a "shape"; subclasses are "rectangle" and "circle" and there's a further subclass of rectangle that's a "square".
The data in the first example was stored on the stack - meaning that it was lost / out of scope at the end of the routine in which it was set up, and that's hardly good news for a piece of code that wants to call a method to set up a whole load of objects. So in the following example, we modified that code - seen [here] to switch the storage to somewhere more controllable / permanent. As something of an aside on the demonstration, I added a method to let me add circles together by overloading the "+" operator - showing operator overloading in C++. Source is [here].
On a training course, where a single file of course code makes for a clean and shareable demonstration, the examples above work well. However, in extending the example into something that leads the way towards real life applications we want to split the code across multiple files. That way, each section is a manageable chunk. That way, each section can be on a different maintenance cycle and looked after by a different team member. And that way, some of the code sections can be pulled into various different applications in your program suite without being duplicated.
So the next demonstration (and the next thing done by the delegates on the course for their practical too) was to split the code for squares, rectangles, and the main application (a test program in this case) into separate files. In C++, that's slightly more complex, in that source files need to know about the API of the objects they use, via class definitions and function prototypes, which are stored into separate header files loaded by the pre-preocessor. And then we knit the whole thing together using a build environment; there are many of these, but for teaching / learning purposed we use make ... and there's a makefile that controls the build, the test, and I added a cleanup action too. You can see ALL of the files on a single page of source - [here].
When I'm running a C Course, I know that one of the things that's going to take a while to go through with the delegates is going to be pointers. They're good, they're needed, but they're also quick tricky and a bit complex. They're actually there in Perl too and behind everything in Python, but those more modern and higher level languages use them in a way that does not provide the same steep hill to climb during courses.
C++ builds on top of C. So it has pointers. But it also has a lighter-weight alternative, which are references. There's more about them [here] and a complete worked example from yesterday [here].
In training delegates on C++, much of the concentration is (and has to be) on Objects and the OO nature of the language, and it's easy to overlook some of the more basic things such as input and output in the examples that we use. So - pulling the various aspects toghther again - I wrote a more complete application that included data file handling, transferring incoming data records from a file into objects in the program. The source of the "base example" is [here].
Moving forward from that base application, I added a factory method to my code to place the logic that converts a file to objects into the class itself. That's usually a natural thing to do, as the data file format wil be shared between all the applications that use the data, and the way it's interpreted should be hidden within ("encapsulated in") the class, rather than being left to each individual application. The final example is [here] ((it's also using a vector rather than an array since we'll rarely know who much data there will be and can't used a fixed size memory block, and it has file checking, usage line if called up incorrectly, etc)). Data for this example is [here].