I am writing code where I have three header files: figure, triangle, and rectangle. Triangle and rectangle classes inherit the figure class. I have all the functions defined in the class declarations and don't need an implementation file. When I compile, I get this error: error C2011: 'Figure' : 'class' type redefinition. Below is one of the header files for one of the derived classes, the others are more or less identical.

What is the proper method of setting this up?

#include <iostream>
#include "figure.h"

using namespace std;

class Rectangle: public Figure
{
public:
	Rectangle(){cout << "Rectangle Constructor" << endl;}
	~Rectangle(){cout << "Rectangle Destructor" << endl;}
	void erase(){cout << "Rectangle Erase" << endl;}
	void draw(){cout << "Rectangle Draw" << endl;}
	void center(){cout << "Rectangle Center" << endl;}
};

Dani AI

Generated

Short summary: the C2011 "class redefinition" error happened because the same header was pulled into a single translation unit more than once (main.cpp includes rectangle.h and triangle.h, both include figure.h). As observed, preventing multiple inclusion fixes it; confirms that adding a guard solved the problem. 's point about not using leading underscores for guard macros is important — those names are reserved.

Recommended setup and best practices:

  • Use either a conventional include guard or the simpler, widely-supported #pragma once. Avoid macro names that begin with an underscore or double underscore; prefer FIGURE_H or MYPROJ_FIGURE_H.
  • Do not put using namespace std; in header files. That pollutes every translation unit that includes the header; prefer std:: qualifiers or put using in the .cpp file only.
  • Keep heavy headers (like <iostream>) out of header files where possible. If only printing is done in constructors/destructors, move those implementations into a .cpp and include <iostream> there.
  • Functions defined inside a class body are implicitly inline and safe to place in headers. If defining non-member or out-of-class functions in a header, mark them inline to avoid ODR violations.
  • If Figure is intended as a polymorphic base, give it a virtual destructor.

Minimal header skeleton (use instead of inlining lots of implementation in headers):

#pragma once

class Figure {
public:
    Figure();
    virtual ~Figure();
    virtual void draw();
    virtual void erase();
    virtual void center();
};
#pragma once
#include "Figure.h"

class Rectangle : public Figure {
public:
    Rectangle();
    ~Rectangle() override;
    void draw() override;
    void erase() override;
    void center() override;
};

Troubleshooting checklist: ensure the guard is present in every header; check for accidental duplicate class definitions in different files; do a clean rebuild after adding guards; and verify include paths so the same header file isn't pulled in via different relative paths.

Recommended Answers

All 5 Replies

Chances are we don't know what the problem is without seeing the code.

#include <iostream>

using namespace std;

class Figure
{
public:
	Figure(){cout << "Figure Constructor" << endl;}
	~Figure(){cout << "Figure Destructor" << endl;}
	void erase(){cout << "Figure Erase" << endl;}
	void draw(){cout << "Figure Draw" << endl;}
	void center(){cout << "Figure Center" << endl;}
};
#include <iostream>
#include "figure.h"
#include "rectangle.h"
#include "triangle.h"

using std::cout;

int main()
{
	Triangle tri;
	tri.draw();
	cout << "\nDerived class Triangle object calling center().\n";
	tri.center();

	Rectangle rect;
	rect.draw();
	cout << "\nDerived class Rectangle object calling center().\n";
	rect.center();
	return 0;
}

This error occurs because you are including a certain file multiple times and therefore trying to redefine the Figure class.

I've always been taught to wrap my class header files in the following format to prevent multiple definitions:

#ifndef __IN_HEADERNAME
#define __IN_HEADERNAME

  //
  // The original header goes here
  //
#endif

>#ifndef __IN_HEADERNAME
>#define __IN_HEADERNAME

The rules for leading underscores in names can be tricky, and it's easy to stomp all over the implementation's reserved identifiers. Unless you're intimately familiar with the rules (which you're clearly not), I'd recommend not using any leading underscores at all.

Yup adding the #ifndef worked, thanks! Taking the second level programming class at a different school so i think im missing out on some things.

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.