Note that I'm not saying any good things about your project not because they aren't there, but because it just doesn't suit my disposition.
Now, if you're going to continue with C++, you should spend some time learning C++. You write C++ like a C programmer. For starters, why are you using malloc? You're writing C++. Using "malloc" or "realloc" in C++ is a huge mistake. You can't just take any old array of type T and call realloc on it. Why not: Because realloc does a raw memory copy, instead of calling the objects' copy constructors. Your 'T' might be a datatype that looks like this:
class foo {
int[10] nums;
int* current;
public:
foo() { current = nums; }
foo(const foo& other) {
for (int i = 0; i < 10; ++i)
nums[i] = other.nums[i];
current = nums + (other.current - other.nums);
}
void add(int n) {
if (current < nums + 10)
*current++ = n;
}
void get(int i) { return nums[i]; }
};
This class's implementation depends on its location -- if you just copy its raw memory, your class will behave erratically.
The same goes for malloc:
a = (T*)malloc(n*sizeof(T)); is just horrible -- your T's will never get constructed!
#define ITER1(x) for(int n1=0; n1<x; n1++)
#define ITER2(x,y) for(int n1=0; n1<x; n1++) \
for(int n2=0; n2<y; n2++)
These macros are unsafe and insane.
[[Edit:
They are unsafe because ITER1(f()) will call f() each time through -- and the user has no way of realizing this. They're insane because they're insane.
A slight, but incomplete, improvement, would be to use the following:
#define ITER1(x) for(int n1 = 0, e1 = (x); n1 < e1; n1++) . There's still the problem that they introduce variables. If the user has a variable named n1 in play, or in my example, e1, they would get unexpected behavior.
It would be better to let the user supply his own iterator variable name, and the ending variable name should be something completely unpredictable. But using EACH1 is still insane.
]]
Why do you have your own BDArr and BDFifo implementations anyway? There is
std::vector and std::queue for a reason...