That is an example, your job is to fill in the fine detail. You will learn much more by trying it yourself than if someone else writes it for you. As an exercise you can try different values of num also.
I've had a quick look, and IMHO the code is severely lacking. Most importantly, the classes are often passed by value instead of by reference. Therefore, every time a hard copy is created. Apart from potential issues regarding performance and memory for more complex object instances, this also means that any code attempting to modify an object using these calls will not work!
Example: the destructor code passes the object that is to be destructed by value!? This will allow you to clean up resources such as pointers to allocated secondary objects, but if you're managing something more complex, such as a database connection or file handle, you're going to have severe issues, if you can properly clean this up at all!
Similarly, the sound() functions create local hard copies of the object that in this case is correctly being passed by reference. Why the author did this is beyond me - it generates needless overhead and ensures that you can not modify the original object. Most importantly, modifying the local copy will not change the behavior of the referenced object that was passed to the function, i. e. the effect of these functions is zero!
Also the example main function doesn't show inheritance at all, because it always directly calls the sound() function on the class interface it is created as (e. g. calling dog.sound()). The only way to prove there is something like virtual inheritance at play is to store the cat and dog objects as animal references, and call the sound() function via the animal class interface. Without actually trying, I predict however, it won't work, because the "derived" sound() functions won't be called, and, therefore, the super class won't adjust it's behaviour.
Always referencing class objects through pointers would go a long way to fix the code and get it towards what the author originally intended. But that still wouldn't introduce polymorphism or encapsulation.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Returning a struct is indeed valid C. It's even given as example in section 22.214.171.124 of the C11 standard, which deals with the return statement.
The return is done with a dumb bit by bit copy. This works very well for struct composed of fundamental types. But as soon as you have pointers in the struct, you need to be extremely careful about who owns an object and shall invoke (manually) the destructor: there is a high risk of nasty memory deallocation errors here !
The more efficient approach would be to return pointers as you suggested. But then, you'll have a high risk of memory leakage, in case the caller is not interested in the returned value (in other functions than the constructor).
The safer way would be to design the API to encourage the caller to provide a pointer to the struture to be used, that he is responsible of (whether it's mallocated or local):
newClassAnimal(&a); // reuse the existing structure
pa = newClassAnimal (NULL); // or allocate a new one. // here the caller is aware that he has to manage the object
I used very long time ago these kind of structures. The function pointers prove to be very efficient way to implement polymorphism in a non object language like C. However the management of the object has its drawback: no automatic destruction, and hence high risk of leakage for more complex execution flows, and especially if you use setjmp/longjmp.
I wrote a VC++ 6.0 application few years back that we still use. Its basically a Dialog based application with a parent dialog and few child dialogs. Most of the child dialogs have something to do with drawing upon requests from parent dialog. The application itself is multi- threaded. Most of the drawing on some dialogs is done using gdiplus and for a couple using just MFC drawing functions. The only issue is have with this is that it flickers a bit and that flicker rate is different on different systems.
We are now thinking of redeveloping the application on VS2010 as support for XP which supports VC++ 6.0 has ended and its getting harder and harder to get PCs with XP on them or even to install XP. I am looking at some best options to choose from to implement in VS2010 for real-time drawing without flicker issues while the core structure will be the same for most part. We will be sticking with dialog based application again as we don't see any real use for SDI or MDI based application in our case. The core of the program is dependent on frames captured from a scientific camera and do some analysis on that frame and do the following
Draw the captured frame on a dialog and draw some graphics (squares/lines) on the same frame based on analysis
4 more dialogs (in which one will have plots in it) will draw/refresh with new analysis data for that frame. I am looking at few options like
OpenCV (which we already use in other applications)
Direct2D (my application doesn't involve any 3D graphics)
GdiPlus (not sure if this works better on VS2010)
GDI+ works. I suppose flickering is an application problem (it is not a library fault).
If you already know OpenCv then using it is an option (as far as I know is rather optimized).
I would use Direct2D only if performance really matters, because (I suppose) the learning step could be heavy.
On a completely different approach, I would also consider using C# instead of C++ with MFC.
Thanks for your reply Pallini, I need to interface external hardware in this application that come with C++ api than C#, so I am a bit stuckw ith C++/MFC combo I guess.
Basically I get a 512x512 8bit pixel data from a framegrabber which I need to display in realtime and even draw some graphics on this image as needed (mostly squares, dots and lines) based on a colorbar.
You need to double buffer the output. Create a bitmap in memory; copy from your frame to that bitmap, then draw your extra graphics on that bitmap. Then when it's done draw it to the screen in one blit. That's how you get rid of the flicker. Gdi+ will do it fine.