Saint Louis University |
Computer Science 146
|
Dept. of Math & Computer Science |
Topic: Inheritance Design
Due:
11:59pm Wednesday, 13 April 2011
Please make sure you adhere to the policies on academic integrity.
In class, we outlined a new high-level design for our matrix suite. It makes use of inheritance to avoid the unnecessary repetition of implementation details. Specifically, we rely on the definition of an abstract base class named matrix_expression, which serves as the parent of two concrete classes named matrix and matrix_proxy.
In this assignment, we explore the details of the design and test your intuitions for what behaviors can be easily reused and what behaviors are specific to one class. For example, in the previous assignment we explored various forms of addition. What you hopefully noticed is that doing addition of proxies with each other, or one proxy and one matrix, is really the same logic as when adding two matrices; in all cases we needed to create a new matrix instance, and then to set the elements to be the sum of the respective elements from the two operands. In our new design, we will place this implementation at the level of matrix_expression, so that it can be shared by all. Its formal signature will be described as
matrix matrix_expression::operator+(const matrix_expression& other) const;Each part of that declaration is important in the design. In general, it uses the form:
returnType class::function(params);In this particular example, we note that by defining the behavior in the matrix_expression class, and taking a parameter that is also a matrix_expression, it can be applied to any expression B+C in our hierarchy (e.g., a matrix plus a matrix, a proxy plus a proxy, a proxy plus a matrix). We also note that we have declared the return type to be a matrix instance. So even when adding two proxies, the result is a matrix rather than a proxy. This is because the values in the sum do not exist in any other location before this operation, so we need to create an underlying matrix to store those values.
We want to test your intuitions as you consider many subtle cases that may arise in our new framework. For each of the following sample syntaxes, consider where and how you think such a behavior is most naturally defined. In particular, we want you to give a complete signature using the form shown above. Make clear in which class the behavior belongs, the type and form of the parameter passing and the return value. Make sure to rely on your understanding of the inner-workings of the matrix and matrix_proxy classes.
For each of the following, you are to given the full signature, and you must provide a written explanation for why you have chosen such an answer. We will get you started with our answer to #0.
matrix matrix_expression::operator+(const matrix_expression& other) const;
The syntax A+B is supported by the operator+ function in C++.
We place this behavior in the matrix_expression class, and
with a matrix_expression parameter, because we are able to
add any two objects that qualify as matrix expressions (e.g.,
The two occurrences of const are there because the evaluation of expression A+B should have no lasting effect on either of the individual operands. Rather, it should generate a new resulting sum.
We have chosen matrix as the return type because we need to create new storage for the result, as the element sums are not explicitly stored in either of the individual operands.