Strings, Garbage Collection and Variable Scope in C++
Archive - Originally posted on "The Horse's Mouth" - 2010-11-25 06:02:03 - Graham EllisIn C, you'll handle strings as arrays of chars (type char *) and that does work - but with grumbles from the compiler about deprecation - in C++. The more modern (or shall we say "more OO") approach is to handle strings as objects - and those will be objects of type string, with headers loaded via
#include <string>See [here] for an (offsite) listing of the various applicable methods, and [here] for a sample in which I've set up a couple of strings, concatenated them, and printed them out to get you started.
The challenge on the C++ course was to write an example that involved Christmas, and the challenge was answered by an example concerning public holidays. Some public holidays are on fixed dates - Christmas day is always 25th December, and others are always fixed days of the week - the August Bank Holiday is always a Monday. There are a few other differences too (such as whether or not supermarkets are legally allowed to open), but much is the same.So on that basis, we designed a base class called "Holiday" and then two subclasses called "Daybased" and "Weekbased", with the common code in the "Holiday" class and methods that changed in the subclasses.
The example - source code [here] - includes demonstrations of a number of features that go rather beyond a first example of polymorphism. You'll find a factory method called "builder" which creates an object of a type that it decides on internally. You'll find a call from the subclass constructor to a non-default base class constructor (by default, a no-parameter base class constructor is called). You'll find multiple inheritance demonstrated. You'll find a virtual method to allow us to handle all types of Holiday from within base class objects, even including the differing behavior, and you'll find all the public holidays for the year loaded into a vector rather than an array, as I wanted to use a construct that was extend-able.
Illustration - City Hall, Belfast provides the backdrop for the Christmas market - photo taken in the evening as I waited for my boat back to Birkenhead
C++ variables are scoped to the block in which they're declared, and they're usually stored on the stack, being lost upon exit from the block as the stack is reduced. Variables declared within an inner scope temporarily mask out access to variables of the same name declared in an outer scope - there's an example showing this [here].
That example's a real "tutor's example only". In a real live application, you would rarely set out to use the same name three times over within 20 lines, but the facility does have its uses. Are you familiar with lines like this:
this->dom = dom;which says "the dom parameter is stored into the dom variable within the current object". I could have written the code using two different names and the the this-> would have not been necessary, but the common idion is to use the same name, and it's an idiom I have to agree with as it saves the need for coming up with several names for the same parameter / attribute / property, and the confusion that would ensue if you did so.
Since variables are scoped in this way, and stored on the stack, the release of their memory is intrinsic on block completion and it can be automatically reused without them needing to be garbage collected. However, where variables are created / stored on the heap via new, that's not the case and you do need to think about garbage collection in your program. Internally, new uses malloc and you should use delete to free up object memory. That way you have control over your own storage, which is probably a fair balance for a language that's designed to give full and low level control whilst providing full OO facilities - but this balance is provided at the cost of potentially programs that take longer to write, and that keep growing as they run if you get them wrong.
There's a garbage collector for C++ which works with most compilers [here] if you want one - and you'll find the full technical stuff there. Note for newcomers o garbage collection ... most of the languages we teach such as Java, Perl and Python have their own garbage collectors - routines to gather up redundant memory for re-use - built in, so you're saved coding them yourself at the expense of slight and non-totally-predictable apparent pauses as your application runs.