macOS Class redefinition error

[datscha]

Hi everyone,

First of all I'm pretty sure I'm not the first one to get this error but every similar thread I found either didn't get me an answer or wasn't relevant enough.
So, why not try creating my own thread?

In some obscure Financial Engineering class, I have to use different math transforms (some using fft).
In order to make it work I had to create two classes: Complex and Options.

The first time I ran my code, in order to test the methods within the classes, everything worked fine. But now, everytime I build, I get a Semantic Issue - Redefinition of 'Complex' // 'Options'.
Then XCode points out the fact I included the header files in other .cpp // .h files and they tell me the previous definitions are there.
I really don't get what I should do!

BTW, I'm under Snow Leopard and using XCode 4.0.1

Below my header for one of my classes, and I'm #includ-ing it in several other files.

Thanks!

class Complex {
public:
    Complex(float realpart=0, float imaginarypart=0);
    Complex Add(const Complex &c) const;
    float GetReal() const;
    float GetImaginary() const;
    void SetReal(float r);
    void SetImaginary(float i);
    void fft(double* x);
    Complex Multiply(const Complex &a) const;
    Complex power(float p) const;
    float norm() const;
    Complex coshC() const;
    Complex sinhC() const;
    Complex cothC() const;
    float arg() const;
    Complex expComplex() const;
    void outprint() const;
private:
    float real;
    float imaginary;
};

 

[willieva]

You're probably including it multiple times, which is why you're getting the error.

It's always a good idea to wrap your include files with an #ifndef based on the name of the include file. So for your file you'd put the lines:
#ifndef _COMPLEX_H
#define _COMPLEX_H 1
//your file here
#endif

around your file. This will keep it from being included more than once.

 

[datscha]

Thanks a lot!

I now remember a vague chapter about files being included several times on an online tutorial.

Now I can go back to my wonderful tranforms..!

Have a good day! And thanks again for the quick answer

 

[Sander]

You're probably not interested in talking about style at this point, but I can't help but comment. Why did you decide to make your math functions members of the class..?

 

[datscha]

You're probably not interested in talking about style at this point, but I can't help but comment. Why did you decide to make your math functions members of the class..?

Well I actually didn't think this through. I just threw all the functions related to the Complex class in there. I'm not good at all w/ these stuffs. I just try to code my algorithms.

 

[Sander]

The best time to start worrying about style and code organisation is when your projects are still small. On the other hand, people commenting on these issues (like me) will seem pedantic, because our warnings ("it'll make your code easier to understand and maintain") will seem like overkill ("I can understand my own code perfectly fine, thank you.") I know, because I've been there.

There are several reasons to define those member functions as standalone functions. One is the principle of least surprise (a.k.a. look how it's done for other types, and mimic that). After all, the code below looks asymmetric:

float f = 1.23;
float cf = cosh(f);

Complex c(1.2, 3.4);
Complex cc = c.coshC();

One other reason is that when you're defining your own types, you want them to be "minimal and complete". In other words, you should be able to point at your class at some point in time and say "that's finished", preferably early in the development cycle. When you can write a function operating on your class without making it a member, then it's often a good idea not to make it a member.

For extra bragging rights, you could define your own operators, so that your math expressions will look just like you'd write it on paper. I still find this the single most sexy feature of C++.

 

[danwilliams]

For extra bragging rights, you could define your own operators, so that your math expressions will look just like you'd write it on paper. I still find this the single most sexy feature of C++.

Word! Us engineers love sexy. We just have a problem getting up enough courage to walk over and talk to them.

 

[chrono1081]

The best time to start worrying about style and code organisation is when your projects are still small. On the other hand, people commenting on these issues (like me) will seem pedantic, because our warnings ("it'll make your code easier to understand and maintain") will seem like overkill ("I can understand my own code perfectly fine, thank you.") I know, because I've been there.

There are several reasons to define those member functions as standalone functions. One is the principle of least surprise (a.k.a. look how it's done for other types, and mimic that). After all, the code below looks asymmetric:

float f = 1.23;
float cf = cosh(f);

Complex c(1.2, 3.4);
Complex cc = c.coshC();

One other reason is that when you're defining your own types, you want them to be "minimal and complete". In other words, you should be able to point at your class at some point in time and say "that's finished", preferably early in the development cycle. When you can write a function operating on your class without making it a member, then it's often a good idea not to make it a member.

For extra bragging rights, you could define your own operators, so that your math expressions will look just like you'd write it on paper. I still find this the single most sexy feature of C++.

Excellent advice!

I remember having a professor who graded heavily on style. The students in the class with messy code got zeros (and tons of feedback on why). After about the third week everyone was writing beautiful looking code and the learning experience was much better for everyone, especially when group work began.

 

[Mac_Max]

Haha and if you don't learn the importance of clean code formatting and documentation now, you will when you come back to something you wrote six months after the fact and say to yourself "who the &#%@ wrote this crap!? I can't understand it!" .

 

[Sander]

Word! Us engineers love sexy. We just have a problem getting up enough courage to walk over and talk to them.

I'm over my shyness with compilers now. I found that although they can give very cryptic feedback when you're saying the wrong things to them (especially in C++), the rewards when you finally get it right are very high.