At least one of your problems is that in "player.h" you have
#ifndef player.h
#define player.h
"player.h" is not a legal pre-processor symbol. Did you mean
#ifndef player_h
#define player_h
?
Secondly, conception.cpp doesn't #include anything.
Third, your class definitions are largely invalid.
class Foo()
is not legal, nor is
class Foo() : public class Bar()
What does '()' have to do with a class name? Are you thinking of the constructor?
Then there is this
char = "Conception";
You can't assign a value to a type.
----- Feedback to help you clean up the code -----
. Choose a style
Or - if you are working with someone else's code, take theirs.
But stick with it.
A huge percentage of software defects that make it past initial development are there because they were hard to spot - missing semi-colons, missing {s around compound statements, etc. C.f. "CARD_H" vs "player.h".
. Inconsistency is the mother of most bugs
classType = new char[11];
char = "Conception";
You probably mean
classType = new char[11];
classType = "Conception";
but this is a memory leak and a bug waiting to happen. In Card:: you do it more correctly
name = new char[strlen(to_copy.name) +1]; // creating dynamic array
strcpy(to_copy.name, name);
The version you use elsewhere
classType = new ...
classType = "String";
allocates some memory, stores the address in classType. Then it looks up the variable of the compiled char* array "String\0" and stores it's address in classType instead.
When the class goes away, it will try to delete the static string and crash.
If this is a learning exercise and you're trying to learn about memory management, this general approach may be fair enough. But placing ownership of pointers in your classes like this is a sure-fire way to wind up with memory leaks and undefined behavior bugs.
It's best to encapsulate pointers in an RAII-style class (a class which owns the pointer and does the delete when it goes out of scope). Take a look into "std::unique_ptr", "std::shared_ptr" and "std::weak_ptr". For your purposes, "std::string" may help you reduce the number of defects by eliminating a lot of the managerial overhead.
. Try to avoid mixing initializer lists with assignment lists.
It's generally better to use one or the other. You can probably get away with using initializer lists when all of your members can be initialized that way, but if they can't, it may be better to use assignment.
Foo() : m_a(), m_b(), m_c() { m_b = 1; m_c = 2; } // is m_a not having a value a bug or intentional?
. Distinguish member variables from ordinary variables.
You're going to run into bugs where values dissapear on you as a result of shadowing: Shadowing variables
#include <iostream>
int i = 0;
int main() {
int i = 1;
for (int i = 0; i < 10; ++i) {
int i = 2 * i;
std::cout << i << std::endl;
}
return 0;
}
when you don't distinguish your member variables (a lot of people use an "m_" prefix, others use a "_" suffix) this is GOING to happen to you frequently.
. Don't assign numeric values to pointers.
name = 0;
while this compiles, you're setting yourself up for less obvious cases appearing to be numbers and Bad Things Ensuing.
abilities = 0;
No, I'm superman, I have ALL the abilities.
abilities = 42;
Two more correct ways to do this would be
name = NULL; // Traditional C++
or
name = nullptr; // C++11
You've done this in someplaces, again consistency is failing you.
. (minor but it'll bite you in the ass in a few weeks) "it" is generally used to reference an "iterator", you might want to use "data" or "value" or "element".
. avoid making members of classes/objects public.
Your "Node" class looks incredibly buggy (the destructor deletes both prev and next???) and you can't tell, from looking at the class, how the "it" pointer gets set, presumably because that happens elsewhere. Where else do you tamper with the "it", prev and next pointers? Encapsulate.
. 'const' can be your friend (by being a pain in your ass)
if (to_get.class = "Spell"){
This will assign "Spell" to to_get.class, causing a memory leak and other issues, and then succeed -- "Spell" evaluates to a fixed const char* address, which is non-zero, which is therefore true.
(It also doesn't compile because 'class' is a keyword and the actual variable is 'className').
You can prevent this by protecting your actual members and only exposing them thru carefully chosen accessors.
const char* Class() const { return m_className; }
Let me break this one down:
const char* :- you cannot modify the contents,
Class() :- instead of to_get.class you'll use to_get.Class()
const :- this function does not have side-effects on the object
The last part means that it can be used on a const object.
class Beer {
bool m_isFull;
public:
Beer() : m_isFull(true) {}
// non-const function, has side-effects (changes isFull);
void drink() { m_isFull = false; }
// const function, returns a copy of "m_isFull". you can
// change the value that's returned, but it doesn't affect us.
void isFull() const { return m_isFull; }
// example of a non-const accessor, if you REALLY want
// the caller to be able to modify m_isFull for some reason.
const bool& getIsFull() { return m_isFull; }
};
. Lastly: Learn to isolate concepts and algorithms.
A lot of the mistakes/bugs/errors in the code appear to be because you're not 100% with some of the nuances or even details. That's not unreasonable, but you need to find a way to be able to try out the little bits of the language.
Take a little time to learn to roll out micro-programs on something like ideone.com. If you are using Linux, make yourself a "srctest" directory with a "test.cpp" and "test.h" and a Makefile
Makefile
all: srctest
srctest: srctest.cpp srctestextern.cpp srctest.h
g++ -o srctest -Wall -ggdb srctest.cpp srctestextern.cpp
srctest.cpp
#include "srctest.h"
#include <iostream>
// add your other includes here and just leave them.
int main() {
return 0;
}
srctest.h
#ifndef SRCTEST_SRCTEST_H
#define SRCTEST_SRCTEST_H
// anything I want to test in a .h file here
#endif
srctestextern.cpp
#include "srctest.h"
// Anything you want to test having in a separate source file goes here.
If you're using visual studio, set yourself up something similar.
The idea is to have somewhere you can go and drop in a few lines of code and be comfortable stepping thru what you're trying in a debugger.
Being able to quickly localize problems is a key part of being a successful programmer as opposed to being an employed code monkey.