CS 2605 Lab 8 Spring 2008

Transcription

1 Inheritance: Logic Gates Goal In this lab, you will consider the use of inheritance in designing and implementing a collection of logic gates. A logic gate is a simple device that receives one or more Boolean values as inputs and produces a Boolean result by combining the inputs using a simple Boolean function. The most common logic gates compute simple Boolean operations. Logic gates may be connected together, using wires, to form larger circuits that compute more complex Boolean functions and even arithmetic results. (That's one reason you'll enjoy CS 2504.) Initially, we will consider a small set of logic gates, implementing the Boolean operations NOT, AND, and OR. Learning Objectives understanding the selection of sensible abstract types for an inheritance hierarchy understanding how to assign responsibilities to the various levels of an inheritance hierarchy experience with the syntax of inheritance experience with simple uses of exceptions exposure to the notion of polymorphism, and how not to achieve it Warmup Analysis of the type relationships To focus the following discussion, let's assume that we will have a Wire type, and that Wire objects will store a Boolean value, and provide a way to set that value and a way to retrieve that value. At this point the details of the interface do not matter. Clearly, we must have classes to represent the three gate types named above. What are the likely attributes and methods for a logic gate? Every logic gate must provide a way to connect one or two input wires and one output wire to itself. Then, the gate will be able to retrieve the value(s) from its input wire(s), and set the value of its output wire. In order to implement complex circuits made up of logic gates, the gate should provide some way to trigger the act of updating its output value. Some logic gates will take one input wire and some will take two. We could consider gates that took more than two inputs, but that doesn't really contribute anything interesting to the inheritance issues, so we will limit our consideration to oneinput and two-input gates. It's certainly possible to derive a two-input gate type from a one-input gate type, but there's no clear advantage in doing so. What is clear is that we have the abstract notion of a "gate", independent of the number of inputs it takes, and of the specific Boolean specific function it evaluates. Here's one possible organization: Gate notgate andgate orgate While this would be workable, it doesn't take advantage of the commonalities we would expect between AND and OR gates. For example, both would provide for two input wires and one output wire. And, it's possible we may think of additional one-input gate types, that might have significant commonality with the NOT gate. So, we will modify our design to incorporate two intermediate abstract types: 1

2 Gate Abstract types oneinputgate twoinputgate notgate andgate orgate Concrete types This will do for now. The Gate class serves only as an anchor for the hierarchy. It doesn't need any data members (we might envision having a zero-input gate type eventually), but it should declare any member functions that are common to all of the derived types (the deep reason for this will become clear later). So, we might settle on something like this: class Gate { Gate() { bool Eval() const; ; The one-input gate type then should add provisions for an input wire and an output wire, with an appropriate constructor, so we might settle on something like this: class OneInputGate : public Gate { OneInputGate(Wire* In = NULL, Wire* Out = NULL); protected: Wire* min; Wire* mout; ; We make the data members protected rather than private, so that the types we derive from this will have access to them. We may provide a specialized version of the inherited Eval() function, but since this is still an abstract type the inherited version is probably sufficient. The two-input gate type would be a simple modification of the one-input gate, adding a second input wire and making the necessary changes to the constructor. Finally we must consider the concrete types. One possible version of the not gate class is shown below. The class must override the inherited Eval() function so that the gate sets its output wire to store the negation of its input wire. class notgate : public OneInputGate { notgate(wire* In = NULL, Wire* Out = NULL) : OneInputGate(In, Out) { ; bool Eval() const; You will find source implementing the specified gates on the Lab page. You should download it and examine the implementations carefully. If there's something in the implementation you don't understand, ask the TAs questions immediately. 2

3 Part I: Incorporating exceptions (weight 25%) The design we arrived at above, and the implementation we provided, are certainly imperfect. For example, what implementation would we provide for the Eval() function in the Gate class? The truth is that since Gate objects cannot have input or output wires, it makes no sense to call the function on one. On the other hand, it seems we must provide an implementation. (We'll see later that 's not really the case.) One possibility would be what's shown in the given code: bool Eval() const { return false; The problem with this is that it's fundamentally dishonest, since it returns a sensible value in response to a nonsensical call. In C++, the idiomatic solution would be to have the function throw an exception if it's called. So, we might provide a specialized kind of object to throw and then modify the implementation of Eval() to throw one of them: class IncompleteGate { IncompleteGate(std::string Msg = "unspecified") { mmsg = Msg; std::string Msg() const { return mmsg; private: std::string mmsg; ; bool Eval() const throw(incompletegate) { throw IncompleteGate("Cannot evaluate abstract gate."); The exception class is based on the design used in the Standard Library for some of the standard exceptions. The thrower can insert an appropriate, specialized message into the thrown object, which could be useful in debugging client code. Decide who will drive during the part of the Lab. Modify the given code to incorporate the exception class (just add it to the Gate header file. Then update the implementation of Eval() as shown above. Now, write a small driver program, declare a Gate object, and call its Eval() function. The program should terminate abnormally when you execute it, since the call to Eval() will result in an exception. Once you've experienced that, rewrite the driver code so that the exception is caught: Gate G; try { G.Eval(); catch (IncompleteGate e) { cout << "Caught exception: " << e.msg() << endl; Now, if you execute your driver, you should see a normal termination after the message is written out by the catch clause. This is as much as you need to know about how to use exceptions, for now. We will discuss further details of C++ exceptions in class. There's no need to modify the implementations of OneInputGate and TwoInputGate, since they will inherit the modified version of Eval() from Gate. But, we do need to modify the concrete gate types since they override Eval(). Basically, we need for those gates to supply versions of Eval() that also throw an exception, but only if the gate object hasn't been provided with a full set of input and output wires. 3

4 Modify the supplied implementations of the concrete gate types so that their Eval() functions also throw an appropriate exception when appropriate. Test your implementation, then zip up the files for your gate classes (but not the driver code) and submit that to the Curator under the heading Lab08PI. Each member of your group must make a submission. Part II: Creating a truly abstract class (weight 25%) The changes specified above will remove one objection to our current implementation. However, it would be even better if we could prevent the client from even creating objects of any of the abstract types. But how can we impose such a restriction? It's actually very simple. If there is no way for the client to call the constructor, then there's no way for the client to declare an object. But, if we were to make the Gate constructor private, then its subtypes could not call it either. (Since the Gate constructor is empty, this may not seem to be a serious objection.) Switch drivers. First, try modifying the Gate class so that its constructor is private. Now compile your code (with the driver you used in Part I). What happens? Modify your driver so that it doesn't declare a Gate object, but it declares one of the concrete gate objects. Now compile your code. What happens? Do you understand why this won't compile? If not, ask for an explanation. OK, making the Gate constructor private isn't an option. But there is another alternative to making the constructor private. Modify your Gate class to use that option and repeat the earlier testing. When you are convinced that it's not possible for client code to declare objects of any of the abstract types, but it is possible to declare objects of the concrete types, move on to Part III. There is no Curator submission for this part. The changes you just made will remain in your code until the end of the Lab. Part III: Adding flexibility and a connectivity test (weight 25%) Switch drivers for this part. The current version of the hierarchy is better, but the interface lacks many useful features. For example, there's no way to change the wires that are connected to a gate after the gate has been created. Fix that by adding member functions with the following interfaces to the hierarchy: bool addwirein(wire* W); bool addwireout(wire* W); There are some important considerations. First, you should add these at the appropriate level(s) in the hierarchy. You should minimize the burden on a future developer who wishes to add new gate classes to the hierarchy. The two-input gates are commutative, so there's no reason to distinguish between "left" and "right" input wires. Second, what should the behavior be if the user tries to add an input wire or output wire and all of the gate's connections are already set? How you answer this question doesn't matter as far as our testing code goes, but you should make a reasoned choice; add comments to your function implementations explaining why you chose your particular design. Now, at this point you may have realized that there's some reason to think of adding another function that tests whether the gate object has been supplied with a full complement of input and output wires. The basic logic for this is probably already in your code at least once. However, we will refine this by specifying what values should be returned under the various possible states of the gate: 4

5 Return value Condition 0 All wires are supplied 1 One input wire is missing 3 Two input wires are missing 4 The output wire is missing 5 One input wire is missing and so is the output wire 7 Two input wires and the output wire are missing The return codes are designed so that a return value of zero indicates success (a fully-connected gate), and other return values indicate the precise nature of the error. This is common practice in C library code. Consider carefully where to add this function within the hierarchy, and then implement it, using the following interface: unsigned int TestConnections(); Test your solution to be sure that it works for each concrete gate type. Then zip up the files for your gate classes (but not the driver code) and submit that to the Curator under the heading Lab08PIII. Each member of your group must make a submission. Part IV: Adding a truth table generator (weight 25%) Switch drivers for this part. The final requirement is to add a function that will generate a complete truth table for a logic gate. For example, when called on an AND gate object, this should return a string that contains the following result: In1 In2 Out false false false false true false true false false true true true You must produce your results in precisely the format shown above. You should use an ostringstream object to write the output to a string and then return that. It might help to know that if you have a bool variable, you can print it as "true" or "false" by using the manipulator boolalpha before you insert the variable to the output stream. It might also be useful to know that you can initialize a bool variable with the values 0 (for false) and 1 (for true). The behavior of the function if the gate isn t fully connected is undefined (and will not be tested). The function must conform to the following interface and should be added in the most appropriate places within the hierarchy: std::string Table() const; If you approach this in the logically correct manner, you will encounter a problem that may seem strange. It s natural to have Table() call Eval(). However, if you place Table() into the appropriate classes, you will find that the calls to Eval() do not perform as expected. If you ve done everything correctly so far, your calls to Eval() will result in the throwing of an exception, because the calls will be to the version of Eval() declared in the Gate class. Modify your declaration of the base class Gate so that the declaration of Gate::Eval() is preceded by the reserved word virtual, something like this: virtual bool Eval() Once you ve made this change, the calls to Eval() in your Table() functions should work as expected. We will discuss why this is necessary in class next week. In fact, if your calls to Eval() work without performing the step above, then you ve placed your implementations of Table() in the wrong classes. In that case, you need to rethink your design decisions. 5

6 When you've completed this part, submit a zipped file containing all your class implementations to the Curator under the heading Lab08PIV. As before, each member of the group must make a submission. Backup Lab Work Before leaving the lab both you and your partner should backup your submitted lab work. It is your responsibility to be able to produce a copy of your work. The Curator server is reasonably reliable, and you can download your submissions from it, but it is always best to maintain your own backups. A USB key or ing yourself a copy of your submitted archive are good options. 6