But I don't think this is the best approach. If you're going to use your current error-handling strategy, you should report them via std::cerr, rather than std::cout. If they just restate things that are obvious from the name of the function, leave them off! If you're going to write documentation comments, make them meaningful and professional looking. And "function update X" barely even makes sense. But consider whether you really need comments for these functions at all! It should be obvious by looking at the name that Point::Point is a constructor for class Point, so you can omit that. This makes things look much neater, especially where you have functions with multiple parameters (or parameters with long names). Also, I recommend placing documentation comments above the function definition, rather than out to the side. The code file needs the same treatment applied. Notice how I've standardized on the number of blank lines, outdented my accessibility specifiers, broke member functions up into logical groups, and so forth. This first time, I'll give an example of what I think good formatting would look like: #ifndef Point_h Even if I do not call something out again the next time that it appears, please try to carry knowledge forward! Point classĪs mentioned above, this class definition needs to be better formatted. It has no effect on efficiency in this case, since all of your members are POD types, but it is nevertheless a good habit to get into.Īside from these general comments, I have some further suggestions for improvements that I will present for each class implementation to hopefully make them more manageable. However, you are not using member initialization lists, and I believe that you should. You appear to have a lot of the basic idioms down, including include guards, virtual functions, const-qualified member functions, and so on. Otherwise, you have a nice solid start here. When you come along later and add code, it is too easy to forget to add the braces and introduce a bug. I would further recommend that you always use braces around if/ else blocks, even if you only have one statement there at the moment. I also recommend that you outdent the accessibility specifiers ( e.g., public:, private:, etc.) in a class definition, and that you begin your comments with a leading space for readability. Use a consistent number of blank lines between functions (unless you are separating them for some reason, and then use a consistent multiple of your normal number of blank lines), be consistent in whether or not you put spaces around operators, be consistent in your indentation, etc. All of this needs to be cleaned up because it looks sloppy and makes the code harder to read.Īdopt a consistent style-whatever it may be-and be disciplined about using it. You also have typos in your comments and even a couple of typos in the #endif portion of the header include guards. In many places, your formatting and alignment are inconsistent. Void Point::print() const //function print the value of X and Y Int Point::getY() const //function return Y Int Point::getX() const //function return X Void Point::setY(int y)//function update Y Void Point::setX(int x) //function update X Point::Point(int x,int y )//conatructor of class Point Triangle::Triangle(const Point &x, const Point &y,const Point &z) Triangle(const Point &p1, const Point &p2,const Point &p3) Rectangle::Rectangle(const Point &l, const Point &r) Rectangle(const Point &l, const Point &r) Shape *shapes = Ĭircle::Circle(const Point &l1,int radius)ĭouble getDist(const Point &p1,const Point &p2) ĭouble Polygon::getDist(const Point &p1,const Point &p2)ĭouble distX = ((p1.getX()-p2.getX())*(p1.getX()-p2.getX())) ĭouble distY = ((p1.getY()-p2.getY())*(p1.getY()-p2.getY())) The project is running and working I am not sure that the constructors and destructors are working. Triangle and Rectangle inherit from Polygon. I have the main file from my teacher and built the project base on it. This is my project on inheritance and polymorphism.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |