ISU E9 - Resource handling

Introduction

In embedded system and systems in general one of the most challenging tasks is to keep track of resources and relinquish them when not needed anymore. This is especially the case with dynamically allocated memory

Exercise 1 Ensuring garbage collection on dynamically allocated std::string

This is a basic exercise where we revisit the RAII idiom once more, however this time in an enhanced form, where our goal is to extend it with the SmartPointer idiom.

Recap: If we inspect the code from the ScopedLock class (or idiom) - see below - it becomes apparent that we have no way of accessing the data residing inside the class. These are considered private and, in the specific use case, sacred in order for the idiom to work as intended.

The questions that come to mind are:

• What do we do if we need access?
• Under which circumstances is this a necessity?
• What syntax and semantics do we want?

The answer to these in short form is:

In a situation where dynamically allocated resources are a necessity, a garbage collected approach which incorporates pointer like semantics is desired!

This is exactly what is achieved by combining both the RAII and the SmartPointer idiom.

In this exercise your task is to combine the above two mentioned idioms and write a class that encapsulates a std::string, such that garbage collection is enforced when leaving scope and that we get pointer like semantic syntax/usage.

Implement the below shown UML class SmartString:

The code snippet below can be used to verify that your solution works.

Questions to answer:

• Why must the copy constructor and assignment operator be private with no implementation?  and what is the consequence when these are private?
• If we imagine that these were not private, a SmartString could be copied and multiple SmartString objects could be pointing at the same string and a Smartstring would then be able to delete the data that the others are pointing to.
• What exactly does the operator->() do?
• The operator ->() makes it possible to access the string object directly from the SmartString object.

Code:

Execution:

Exercise 2 The Counted Pointer

In this exercise we are going to extend our fine SmartString, such that multiple parties may have a “reference" to it.

Since we want sharing of the data as opposed to what we did in Exercise 1, the assignment operator and copy constructor must now be implemented.

This leads to this new interface:

Things to be aware and consider:

• Why must the counter be dynamically allocated? Where should this happen?
• The counter must be dynamically allocated because every object using a SmartString must be able to increment the counter.
• How is the copy constructor been implemented?
• By moving what is in the other counter to the new counter that is created and increment it we get a copy because the address of the counter is the same. The address of the new str_ is then passed on to the other counter.
• How is the assignment operator been implemented?
• The assignment operator decrement the counter and release data if check counter == 0, is true.
• What happens in the destructor and how should it be implemented?
• Must make sure to count the counter down by 1 and release whatever the pointer is pointing to because it is no longer needed.

Create appropriate test harnesses to validate that your solution works. These test harnesses must be part of your documentation on the wiki.

Code:

Testprogram:

Execution:

Exercise 4 Discarding our solution in favor of boost::shared ptr<>

During the different exercises we have embarked on a journey where each and every step improves/enhances our previous solution. Other than that we have gained a better understanding of the language that we utilize.

In Exercise 3 we succeeded in creating a viable solution that in reality would improve our programs by making them less error-prone. However instead of reinventing the wheel, we will make a rather large jump and start using the boost library, in particular we will be using boost::shared_ptr<>.

Exercise 4.1 Using boost::shared ptr<>

The template class boost::shared_ptr<> incorporates the different aspects that we have covered and then some.

Use the boost::shared_ptr<> and get to know it. Utilize the different test harnesses that you have concocted and create a new one that verifies that boost::shared_ptr<> works as intended, and that it can be used in the use-cases discussed above.

As stated earlier the test harnesses must be presented on your wikis.

Code:

Execution:

Exercise 5 Resource Handling

Perspective of this particular exercise:

• What do you consider a resource?
• A could be memory, CPU, files, etc.
• In which situations do you foresee challenges with resources and how could they be handled?
• Resources are often things that are limited in our system. If we have a memory leak we use up limited memory. Another challenge is garbage laying around. These are handled by implementing garbage collection and proper deallocating. In our case we use the design principle RAII to automate the task.
• In particular regarding memory, when would you be able eliminate the need for allocations. Or when is it a must that something is allocated (on heap)?
• There is no need to dynamically allocate something if it is used within your own scope. If something is used outside of your own scope you have to allocate it on the heap. If you do not then other classes, functions etc cannot access it.