When we use enumerations, by default the values assigned to enumerations start from zero. Suppose you have two classes with classA and classB with enumeraions defined as below. For classA: enum { santro,zen } cars; For classB: enum { Kinetic,sunny} bikes; Now in a function you get some integer which should indicate the type of car or type bike. void findType(int nType) { if( nType == classA::santro ) { cout< } if( nType == classA::zen) { cout< } if( nType == classB::kinetic) { cout< } if( nType == classB::sunny) { cout< } } Now with such a code you will always find out put as santro kinetic OR zen sunny This is because though while coding we use classA::santro and classB::kinetic, both the variables have the same value i.e. zero. Thus for any value of nType (0 or 1 ), always two if conditions are satisfied, giving the wrong result . So if you are using two enumeraions in a single function you should always make sure to avoid the clash between them. For this we can use the following code to add the offset to one of the enumeraions. enum { kinetic = 100, sunny } bikes; Thus values of the enums bikes and cars, will differ in value and the clashing between the two will be avoided.( You also have to adjust the values of the variable nType passed to the function accordingly.) If two enumeraions are being used in same function, then care should be taken to avoid the clashing between the two. |
1 Introduction This paper describes the use of object-oriented software design patterns, as presented in Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al., within the Microsoft Foundation Class Library (MFC). MFC is used for implementing applications for Microsoft Windows operating systems. Because of the size of the MFC library, a complete analysis would have been beyond the scope of this assignment. Instead, we identified various possible locations for design patterns, using the class hierachy diagram of MFC, and studied the source carefully at these locations. When we did not find a pattern where we expected one, we have documented it anyway, with examples of how the particular problem could have been solved differently, perhaps more elegantly, using design patterns. We have included a brief introduction to MFC in Section 2 , as background information. The analysis has been split into three parts, with one section for each major design pattern ca...
Comments