Hello guyz!
Im conducting a debugging contest...

Im writing some questions... I wrote a code implementing virtual functions..

Im not sure where to include bugs here.. Can anyone help me add bugs to this code??
Please bugs must make people think.. THey must not just be syntactical errors..


Thank you..
Output wil be given to the debugger.. and he will asked to debug the code to produce desired result Thanks!

#include <iostream>
   using namespace std;


   class Shape
   {
   public:
      Shape()
      {}

      virtual long GetArea()
      {
        cout<<"Area";
      }
      virtual long GetPerimeter()
      {
        cout<<"Perimeter";
      }
      virtual void Draw() = 0;

   };

   void Shape::Draw()
   {
      cout << "Shape Drawn!!";
   }

   class Circle : public Shape
   {
   private:
      int radius;
      int circumference;
   public:
         Circle(int rad):radius(rad)
         {
         }

         long GetArea() { 
         return 3 * radius * radius; 
         }
         long GetPerim() { 
         return 9 * radius; 
         }
         void Draw()
         {
            cout << "Circle drawing routine here!\n";
         }
   };

   class Rectangle : public Shape
   {
   private:
      int Width;
      int Length;

   public:
         Rectangle(int len, int width):
            Length(len), Width(width)
          {}

         long GetArea() 
         { 
          return Length * Width; 
         }
         long GetPerim() 
         {
          return 2*Length + 2*Width; 
         }
         virtual int GetLength() 
         {  
            return Length; 
         }
         virtual int GetWidth() 
         { 
            return Width; 
         }
         void Draw()
         {
            for (int i = 0; i<Length; i++)
            {
               for (int j = 0; j<Width; j++)
                  cout << "x ";

               cout << "\n";
            }
          
         }
   };

   class Square : public Rectangle
   {
   public:
         Square(int len):
            Rectangle(len,len)
            {}
         Square(int len, int width):
             Rectangle(len,width)

             {
                if (GetLength() != GetWidth())
                   cout << "Error, not a square... a Rectangle??\n";
             }

         long GetPerim() {
          return 4 * GetLength();
         }
   };

   int main()
   {
      int choice;

      Shape * sp;

      while (1)
      {
         cout << "1.Circle\n2.Rectangle\n3.Square\n4.Quit\nEnter Choice.. ";
         cin >> choice;

         switch (choice)
         {
            case 1: sp = new Circle(5);
            break;
            case 2: sp = new Rectangle(4,6);
            break;
            case 3: sp = new Square (5);
            break;
         }
         if (choice==4)
            break;

         sp*Draw();
         cout << "\n";
      }
     return 0;
 }

Dani AI

Generated

A few notes to shape this into a good debugging contest: aim for semantic and runtime traps that still let the program compile and run. Obvious syntax typos end the exercise too quickly. Seed bugs that force contestants to reason about object lifetime, polymorphism and API contracts rather than just fix a missing semicolon.

Subtle bug ideas that fit the Shape hierarchy:

  • Make a derived method differ just slightly from the base signature (name, const-qualification, default args or return type). It compiles but the function is not overridden, so polymorphism silently fails.
  • Omit a virtual destructor in the base and let a derived class manage a resource. Deleting through the base pointer will leak or corrupt state only at runtime.
  • Call a virtual method from a constructor or destructor; the base implementation will run, not the derived one, which surprises many debuggers.
  • Introduce object slicing by passing derived objects by value to a function taking the base type.
  • Hide members by re-declaring names in derived classes (width/length shadowing) so simple inspections miss the real value used.
  • Add subtle UB: returning a reference to a local, or failing to return a value from a non-void function. These produce strange runtime behaviour without compiler errors.

How to test and judge solutions: require the code to compile cleanly and provide unit tests or expected outputs contestants must match. Encourage use of compiler warnings and tools: enable -Wall -Wextra -Wshadow -Woverloaded-virtual -Wmissing-override, run clang-tidy, and use sanitizers (-fsanitize=address,undefined,leak) or valgrind to reveal memory/UB issues. Make a few small, focused test cases (e.g., delete through base, call Draw during construction, pass by value) that expose each class of bug.

Build difficulty levels by grouping 2–3 traps per variant. As noted, input/validation is fertile ground; as hinted, compile-time/template traps add depth; use -style access surprises sparingly so the contest stays about reasoning, not trivia.

Recommended Answers

All 5 Replies

Remove the word public from a couple of the classes.
Put an =0 on a constructor.
Use the same shape twice on two of your choices.

Well, the most obvious bug is that you don’t have a default case for your switch, and you don’t bounds check the user input. Also, you don’t use Pi to calculate the area of the circle. You don’t use Pi to calculate the perimeter, but if you did, the formula is incorrect.

If I were trying to add more bugs, I would want the user to input the length and width of the shapes. It is very easy to have bug in you code when you are validating or handling data. An example would be reversing the height and width of a rectangle. You could also allow non-integer input from the user. That would make things more interesting.

. Good suggestions.

Thanks guyz!!

Write a templated class that makes some assumptions about the template type. Instantiate it with a type that violates said assumptions. Watch the debugger point you to the constructor when the error is in the instantiation.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.