Mac Class redefinition error

datscha

macrumors newbie
Original poster
Jan 31, 2012
5
0
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!

Code:
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

macrumors 6502
Mar 12, 2010
274
0
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

macrumors newbie
Original poster
Jan 31, 2012
5
0
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

macrumors 6502
Apr 24, 2008
480
7
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

macrumors newbie
Original poster
Jan 31, 2012
5
0
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

macrumors 6502
Apr 24, 2008
480
7
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:

Code:
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

macrumors member
Sep 15, 2008
46
0
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

macrumors 604
Jan 26, 2008
7,660
1,779
Isla Nublar
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:

Code:
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

macrumors 6502
Mar 8, 2004
404
1
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!" :D.
 

Sander

macrumors 6502
Apr 24, 2008
480
7
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.

:)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.