changing an int array

[llemes4011]

Hi, I'm new to C++, I learned to program in Java first. I'm having trouble getting this to work. I'm writing a text based version of battleship. It was going well until i tried to set the size of the ship. I'm using an int array to check to see if the ship has been hit. When i try to set the array size in my constructor, the compiler yells are me =[. Could someone please tell me what's wrong?
Ship.h

#ifndef _SHIP_H
#define	_SHIP_H

enum possition{
    HORIZONTAL, // 0
    VERTICAL    // 1
};

class Ship {
    private:
        int x; //x-pos
        int y; //y-pos
        int size; //length of ship
        int pos; // horizontal or vertical
        int hit[]; // 0=safe, 1=hit
    public:
        Ship(int x, int y, unsigned int size, int pos);
        bool isHit(int x, int y);
        int getX(){return x;}
        int getY(){return y;}
        int getSize(){return size;}
        int getPos(){return pos;}

        ~Ship();
};

#endif	/* _SHIP_H */

Ship.cpp

#include "ship.h"

Ship::Ship(int x, int y, unsigned int size, int pos) { // init values for ship
    this->x=x;
    this->y=y;
    this->size=size;
    this->pos=pos;
    int dummyArray[size];
    this->hit=dummyArray; // I think this is the problem... How do i fix it?
}

bool Ship::isHit(int x, int y){//does a guess hit this ship?
    if(getPos()==VERTICAL){
        if(getX()!=x)return false; // not in the same column
        if(y>getY() && y<getY()+getSize()){
            this->hit[y-getY()]=1;
            return true;
        }
    }
    if(getPos()==HORIZONTAL){
        if(getY()!=y)return false; // not in the same row
        if(x>getX() && x<getX()+getSize()){
            this->hit[x-getX()]=1;
            return true;
        }
    }
}

Ship::~Ship() {
}

And this is the error I'm getting:

Running "C:\cygwin\bin\make.exe  -f Makefile CONF=Debug" in C:\Documents and Settings\Neil\My Documents\NetBeansProjects\Battle Ship

/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[1]: Entering directory `/cygdrive/c/Documents and Settings/Neil/My Documents/NetBeansProjects/Battle Ship'
/usr/bin/make  -f nbproject/Makefile-Debug.mk dist/Debug/Cygwin-Windows/battle_ship.exe
make[2]: Entering directory `/cygdrive/c/Documents and Settings/Neil/My Documents/NetBeansProjects/Battle Ship'
mkdir -p build/Debug/Cygwin-Windows
rm -f build/Debug/Cygwin-Windows/ship.o.d
g++.exe    -c -g -MMD -MP -MF build/Debug/Cygwin-Windows/ship.o.d -o build/Debug/Cygwin-Windows/ship.o ship.cpp
ship.cpp: In constructor `Ship::Ship(int, int, unsigned int, int)':
ship.cpp:10: error: incompatible types in assignment of `int[((unsigned int)((int)size))]' to `int[0u]'
make[2]: *** [build/Debug/Cygwin-Windows/ship.o] Error 1
make[2]: Leaving directory `/cygdrive/c/Documents and Settings/Neil/My Documents/NetBeansProjects/Battle Ship'
make[1]: *** [.build-conf] Error 2
make[1]: Leaving directory `/cygdrive/c/Documents and Settings/Neil/My Documents/NetBeansProjects/Battle Ship'
make: *** [.build-impl] Error 2

Build failed. Exit value 2.

[MrSpigot]

int dummyArray declares an array of a fixed size. 'size' must be a constant known at compile time.
e.g. int dummyArray[5] would work as the compiler knows how much space to allocate.
So your way out of this is:
1. Declare an array large enough to handle your largest expected case, or
2. Check out the STL container classes. The vector class will allow you to allocate what you need at run time.

[Sky Diploma]

not only dummyarray but also the int array hit Should also have a specific size.

[siddhant3s]

While you are searching for the solution, you should know that arrays are evil.
You should be working on STL's std::vector instead of traditional array. The following document can help you migrate : http://siddhant3s.googlepages.com/how_to_tell_rusted_cpp.html#SECTION00052000000000000000

[llemes4011]

thanks a lot for the tip about vectors! I got it working now. Thanks!

[Narue]

>The following document can help you migrate :
>http://siddhant3s.googlepages.com/ho...00000000000000
If I may, I'd like to comment on a few parts of that document.

>2.3.1 Depreciated Header Files
The word is "deprecated". Depreciate means to lessen in value. Deprecate means to declare a feature obsolescent such that while it's still supported, use of the feature is not recommended and it may be removed in future revisions of the standard without warning.

I often have to make it clear that <iostream.h> and friends are not deprecated because they were never a part of standard C++. As such, any use of those headers is completely non-standard.

>Modern compilers do create warning messages about use of depreciated
>header files. If your compiler don't, your probably the victim of section
This statement is false. Compilers are only required to issue a diagnostic for constraint violations. It's incorrect to say that a compiler that fails to issue a warning for use of deprecated headers is an "Old Compiler".

>These depreciated files are not guaranteed to be available on a standard
>implementation hence making your code un-portable and rusted.
Deprecated features are absolutely required to be available on a standard implementation. Deprecated means "obsolescent", not "unsupported". Especially with the standard C headers, most deprecated features are unlikely to be removed from the standard because of compatibility with existing code. The standard committee is more likely to leave supremely dangerous features in the standard (eg. gets) than to break existing code.

As such, it isn't non-portable to use deprecated features. They're deprecated because there are supposedly superior alternatives available.

>[getch()] can be avoided by using cin.get() instead.
Unless the point of using getch is to acquire raw rather than cooked input. getch and cin.get do not have the same behavior. While it's fine to recommend cin.get over getch for keeping a console window open, it's not good advice for all uses of getch.

>If you are too lazy to write std:: more than once
Please don't push your stylistic opinions on others. After reading this, I'd be inclined to ignore all of your advice on the grounds that you're too biased to give consistently good advice.

>It is my strong recommendation that you please don't use the last
>approach. It is a very killing habit. It kills the concept of namespaces.
Rather than show the worst possible usage and then condemn it, why not encourage a better practice? Using declarations and directives are not limited to the global scope. It's a better practice to place your directives/declarations at the smallest possible scope. And of course, when you remove them from the global scope, all of the arguments about killing the concept of namespaces become moot.

>2.5 The use of system() calls
It also couldn't hurt to mention that calling system introduces a huge security hole.

>There is also an alternative to macros: the inline functions.
You neglected to mention that macros, being a mere text replacement facility, supports insensitive typing. To get the full effect of macros, you'd need a template function.

>That means, rather than calling the function, the compiler will insert the
>complete body of the function in every place in the code where that function is used.
The down side is that a request to inline doesn't have to be honored by the compiler. While macros are absolutely inline, inline functions may end up not being inlined at all.

>The use of arrays and explicit memory management should
>be done only when you are designing a library yourself.
What about when speed is paramount and the size is constant? Arrays are extremely likely to be faster because std::vector uses dynamic memory. What about when failure is not an option? Some programs will avoid std::vector and use arrays simply because dynamic memory introduces a failure point that isn't acceptable. Preferring std::vector over arrays is a good guideline, but you're taking it too far.