I will give 5 stars!!!!! Inheritance and polymorphism Consider the following Bug

Question

I will give 5 stars!!!!! Inheritance and polymorphism Consider the following Bug class that models a bug moving along a horizontal line. It has two data member position for the bug's position on horizontal line; and dir for direction the bug is going(left=-1, right = +1) class Bug {public: Bug(): Bug(int); //position = 0, dir =+1 void move();//position=argument, dir=+1 void turn(),//move bug 1 unit in current dir void display();//change the bug direction private: int position; int dir; }; An ant is a bug that has the capability to carry heavy loads of food. In this problem you need to desire an Ant class from Bug class and add the following additional data member: weight-the weight carried by an ant(double). (a) Write definition for the Ant class(derived from the Bug class) with a default constructor, a constructor that will initialize all data member of an Ant object, an accessor function named get_weight, a mutator function named set_weight and a redefined function display to write all the data members of an Ant object to an ostream object. (b) Write the definition for the constructor with parameters for the Ant class. This constructor passed into the parameters. Remember that there should not be a parameter for the dir data member. (c) Write C++ statements to do the following(you do not have to write the entire program, just the relevant statements). Create an Ant object named ant1 for an ant starting out at position 17 carrying 4 units of food. Create a pointer to a Bug object named but_ptr, i.e, a base class pointer. Assign the address of the ant1 object decleared above to bug_ptr. Use bug_ptr and the display function to write the data memer vaues of the Ant object to a data file using an ofstream object file_out(you can assume the file has been opened) (d) What must be done in the definition of the base Bug class to ansure that the correct version of display will be used in part(c)?

Explanation / Answer

In our pseudo-code listing, this concept could be written like so: void main() { // do forever ("MESSAGE PUMP") while(true) { // "translate" the events... every time //"something" happens, // set the variable "message" //to the number that corresponds int message; if ( getKeystroke() ) { message = 1; } if ( exitKeyPressed) { message = 2; } // "dispatch" the events... call a main // event handler to // figure out which sub-event handler to call doEvent(message); } } // MAIN EVENT HANDLER void doEvent(int message) { switch(message) { case 1: onKeyPress(); break; case 2: exit(); break; } } // KEYPRESS EVENT HANDLER void onKeyPress() { doSomeWork(); } This may seem like a round-about way to do things, but messages make it easier for Windows to pass important events between different programs. If the program doesn't know what to do with an event, it can also pass it to the Windows default event handler. The default event handler is just another function that figures out what to do with the event when you aren't sure or simply don't want to deal with it. Following is code for a real Windows program to show you what I mean. This code will compile and run with Microsoft Visual CC++6.0; it should also run with Borland or any other CC++ compiler that supports the Windows API. Just in case you aren't sure, the Windows API is a set of functions, libraries, etc., provided by the operating system to do the basic things that are required by a graphical program. This saves you from re-inventing the wheel every time you write a program; the code for things that all windows programs need, like the basic functionality of a button, is already done for you. Other platforms, such as the Mac or X WindowsMotif, have similar APIs. From my personal experience, I can say that the Windows API is more full-featured and does a lot more things for you than many of the other platforms, at the expensive of being enormous, sometimes over-featured and often overwhelming. The following code will create a basic window. It also handles the PAINT event, and provides a sample function that draws a circle on the window. (I apologize in advance if some of the code wraps funny. You may need to copy and paste this into a mono-spaced editor to read it more clearly.) **********BEGIN LISTING**************** #define STRICT // strict type checking #define WIN32_LEAN_AND_MEAN//exclude seldom-used code #include //needed to write windows code /*----------------------------------------------- Paints the Window Client Area This is your event handler for the PAINT event. For each thing you want to do, such as handle a keystroke or a button press, you'll have an event handler function just like this. Parameters: HWND hWnd - handle to current window. Windows identifies each form and control in an application by assigning it a handle. Most API functions need to know the handle of a window in order to do anything interesting to it. Returns: ---------------------------------------------*/ void onPaint(HWND hWnd) { PAINTSTRUCT ps; // structure for paint info HDC hDC; // handle to graphics device context, //i.e. where to paint // create device context, prepare for painting hDC = BeginPaint(hWnd, &ps); // draw a circle Ellipse(hDC, 0, 0, 50, 50); // update the window client area with //whatever else we want // delete device context DeleteDC(hDC); // end painting EndPaint(hWnd, &ps); } /*---------------------------------------------- Windows Message Pump Callback Routine This is your MAIN EVENT HANDLER. This function takes the events that Windows passes in, figures out what they are, and then calls your additional sub-event handler functions to handle the event. Any events that aren't handled get passed on to the default event handler supplied by Windows (DefWindowProc). This saves you from having to write code for events you don't care about, like, say, a notice that the window was resized. Parameters: HWND hWnd - our window's handle UINT wMsg - message number WPARAM wParam - word parameter, contents differ for each message LPARAM lParam - long parameter, contents differ for each message Returns: 0 if we handled the message, result code otherwise -------------------------------------------*/ LRESULT CALLBACK WndProc(HWND hWnd, UINT wMsg, WPARAM wParam, LPARAM lParam) { // select and handle possible window messages switch(wMsg){ // window created, initialize application case WM_CREATE: // do whatever you need to do on startup here break; // window close suggested case WM_CLOSE: // do whatever you need to do on shutdown here DestroyWindow(hWnd); break; // paint window requested case WM_PAINT: onPaint(hWnd); break; // application terminated case WM_DESTROY: PostQuitMessage(0); break; //pass on other unhandled messages to default handler default: return(DefWindowProc(hWnd, wMsg, wParam, lParam)); } // return 0 if we handled the message return 0L; } /*------------------------------------------------ Main Entry Point -- this is the equivalent of "void main()" for a windows program Parameters: HINSTANCE hInstance - current program instance HINSTANCE hPrevInst -handle to the previous instance LPSTR lpszCmdLine - command-line arguments int nCmdShow - window size/mode Returns: the value of PostQuitMessage ---------------------------------------------------*/ int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInst, LPSTR lpszCmdLine, int nCmdShow) { HWND hWnd; // window handle from create window MSG wMsg; // message from GetMessage WNDCLASS wndclass; // window class structure char *strProgramName = "My Program Name"; // the name of your program // if this is the first instance of the application, register the window structure... // back in the day, system resources were very tight, and programs that used several similar looking windows could save loads of memory by storing only one "design" for a window in memory. new copies of the application in memory, or "instances", could point to the window design that was already in RAM instead of loading it again. even though it's less important today now that computers have gobs of memory, windows still works this way; it has a number of misc advantages. if( ! hPrevInst ) { wndclass.style = CS_HREDRAW | CS_VREDRAW; //window style wndclass.lpfnWndProc = WndProc; //address to event handling procedure wndclass.cbClsExtra = 0; // no extra class data wndclass.cbWndExtra = 0; // no extra window data wndclass.hInstance = hInstance; //handle to the current instance wndclass.hCursor =LoadCursor(NULL, IDC_ARROW); //stock arrow cursor wndclass.hIcon =LoadIcon(NULL, IDI_APPLICATION); //stock icon wndclass.lpszMenuName = NULL; // menu name wndclass.hbrBackground =(HBRUSH)(COLOR_APPWORKSPACE + 1); //background color brush wndclass.lpszClassName = strProgramName; //window class name RegisterClass(&wndclass); } // create the main window. you can change the parameters to this function to make different kinds of windows hWnd = CreateWindowEx(WS_EX_OVERLAPPEDWINDOW, // extended window style strProgramName, // program name strProgramName, // window titlebar caption WS_OVERLAPPEDWINDOW | WS_SYSMENU,// basewindow style CW_USEDEFAULT, // default x position CW_USEDEFAULT, // default y position CW_USEDEFAULT, // default width CW_USEDEFAULT, // default height NULL, //parent's handle NULL, // menu handle hInstance, // handle to the instance NULL); //initialization data // display the main window; unless you make the window visible as part of the window // style you specify, the window is invisible by default ShowWindow(hWnd, nCmdShow); // windows "message pump"... remember that "while(true)" loop that sat around // waiting for events in the pseudocode? well, here it is! through this loop, messages // are parsed and eventually sent by windows to your main event handler, WndProc while(GetMessage(&wMsg,0,0,0)){ TranslateMessage(&wMsg); DispatchMessage(&wMsg); } // return exit code from program, obtained from PostQuitMessage return wMsg.wParam; } **********END LISTING****************

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.