3. C++ Schiffe Versenken

C++ Schiffe Versenken

  • S

    Mach dich auf jedenfall drauf gefasst, dass hier viele Dinge noch genannt werden, die du noch nie gehört hast. Auch wird dir dein Code früher oder später komplett auseinander genommen werden. Dem ein oder anderen geht das persönlich sehr nahe, was es eigentlich nicht braucht.

    Denn:

    die 10-Programmierer Gebote schrieb:

    Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

    You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.

    No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.

    Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

    Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.

    The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

    The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

    Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.

    Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

    Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

    0
  • ?

    nein das würde man so machen:

    std::array<int, 4 * 2> Schiffe;

    und weil es mühsam ist, jedes mal wenn man darauf zugreifen möchte auch noch die indices zu berechnen, kann man das auch kapseln:

    template<class T, ::std::size_t Width_, ::std::size_t Height_>
class Field
{
public:
	typedef T ValueType;
	enum
	{
		Width = Width_,
		Height = Heigth_
	};
private:
	::std::array<ValueType, Width * Height> Underlying;
	::std::size_t TransformIndex(::std::size_t IndexX, ::std::size_t IndexY) const
	{
		return IndexX + IndexY * this->Width;
	}
public:
	ValueType const& operator() (::std::size_t IndexX, ::std::size_t IndexY) const
	{
		return this->Underlying[this->TransformIndex()];
	}
	ValueType& operator() (::std::size_t IndexX, ::std::size_t IndexY)
	{
		return this->Underlying[this->TransformIndex()];
	}
};
    0
  • ?

    also das nein ging an jkhsjdhjs, nicht an dich seppj...

    0
  • ?

    ups, die funktionsparameter bei den "TransformIndex"-aufrufen vergessen.

    ValueType const& operator() (::std::size_t IndexX, ::std::size_t IndexY) const 
    { 
        return this->Underlying[this->TransformIndex(IndexX, IndexY)]; 
    } 
    ValueType& operator() (::std::size_t IndexX, ::std::size_t IndexY) 
    { 
        return this->Underlying[this->TransformIndex(IndexX, IndexY)]; 
    }

    kann ein mod bitte meine drei posts zu einem zusammenheften? 🙂
    jaja ich registrier mich irgendwann mal...

    0
  • J

    @asdfsf:

    Okay...
    Ich hab echt nicht die geringste Ahnung was du da geschrieben hast, hab zwar schonmal von Klassen gehört, weiß aber nicht was das ist. Könntest du vllt mal mit Kommentaren versehen, was du geschrieben hast?
    Und was ist das Ziel von dem was du da geschrieben hast?

    0
  • Mod

    Ich denke, das was asdfsf vorschlägt, ist hier wohl etwas zu hoch für den vorhandenen Kenntnisstand. Ich sehe auch nicht, wozu das hier überhaupt nötig sein sollte, denn es hat keinen Vorteil gegenüber dem verschachtelten Array (siehe mein vorheriger Beitrag), es ist bloß viel umständlicher. Daher würde ich das verschachtelte Array nehmen.

    0
  • J

    Ok, dann werde ich die nehmen. Danke 😉
    Würde ich das hier:

    #define SCHWARZ			0x0000
#define DUNKELBLAU		0x0001
#define DUNKELGRÜN		0x0002
#define DUNKELTÜRKIS	0x0003
#define DUNKELROT		0x0004
#define LILA			0x0005
#define GOLD			0x0006
#define GRAU			0x0007
#define DUNKELGRAU		0x0008
#define BLAU			0x0009
#define GRÜN			0x000a
#define TÜRKIS			0x000b
#define ROT				0x000c
#define PINK			0x000d
#define GELB			0x000e
#define WEIß			0x000f

    dann so schreiben?:

    enum Farben {
	SCHWARZ,
	DUNKELBLAU,
	DUNKELGRÜN,
	DUNKELTÜRKIS,
	DUNKELROT,
	LILA,
	GOLD,
	GRAU,
	DUNKELGRAU,
	BLAU,
	GRÜN,
	TÜRKIS,
	ROT,
	PINK,
	GELB,
	WEIß
}
    0
  • Mod

    Bezüglich Farbenenum: Ist jedenfalls ein Fortschritt gegenüber Makros. Allgemein würde ich Umlaute weglassen, da es auch viele Compiler gibt, die streng auf ASCII für Bezeichner bestehen. Und wenn man schon dabei ist, würde ich auf Englisch programmieren, sofern es keine große Mühe ist. Ist sicherlich gut, sich frühzeitig da dran zu gewöhnen, früher oder später wird man ohnehin auf englisch programmieren.

    0
  • J

    Ja, ich wollte eigentlich auf Englisch programmieren, aber da ich die Ausgaben auch auf Deutsch habe, dachte ich mir mach ich doch alles auf Deutsch. Aber ok, werde es mir merken!

    EDIT: Und wie würde ich die Farben dann verwenden? Weil denen wurde doch jetzt kein Wert zugewiesen, oder?

    0
  • N

    jkhsjdhjs schrieb:

    EDIT: Und wie würde ich die Farben dann verwenden? Weil denen wurde doch jetzt kein Wert zugewiesen, oder?

    Doch.
    Der erste Wert eines Enums erhält die Nummer 0, alle anderen dann aufsteigend.
    Du kannst ihnen aber auch manuell Werte zuweisen.

    0
  • Mod

    jkhsjdhjs schrieb:

    EDIT: Und wie würde ich die Farben dann verwenden?

    Wenn du es so wie hier definierst ( enum name { ... } ), dann gelten die Bezeichner im umgebenden Namensraum (also in der Regel überall, wenn du keine Namensräume benutzt). Das heißt, du kannst wirklich "SCHWARZ" im Programm schreiben und es ist wie eine Zahl mit Wert 0.

    Ab C++11 gibt es neu die "strongly-typed" enums, die mittels enum class name { ... }; definiert werden. Diese unterliegen einer strengen Typprüfung (es ist also nicht mehr möglich, ein Wert aus einem enum dort zu benutzen, wo ein anderes enum erwartet wird) und die Elemente sind nun ebenfalls im jeweiligen Scope des enums. Bei enum Farben {SCHWARZ, ...}; also zum Beispiel Farben::SCHWARZ .

    Was davon besser geeignet ist, kommt auf den Einzelfall an. Die alte Methode provoziert Namenskonflikte. Manchmal sollen die Bezeichner aber auch wirklich überall gelten. Farbwerte sind ein bisschen ein Grenzfall. Man kann leicht Beispiele konstruieren, wo die alte Methode unpassend ist, aber hier würde ich sagen, passt keiner dieser Fälle und ich würde es so machen, wie du es hier vorschlägst.

    Weil denen wurde doch jetzt kein Wert zugewiesen, oder?

    Wenn man nichts anderes angibt, dann gehen die Werte bei 0 los und sind dann jeweils um 1 aufsteigend. Hier passt also alles schon, sofern du keine Farben vergessen hast. Besserer Stil wäre es daher wohl (um solche Fehler zu vermeiden) allen Farben einen Wert zu zu weisen:

    enum foo
{
  hundert = 100, 
  tausend = 1000, 
  million = 1000000
};

    P.S.: In deinem Codebeispiel fehlen übrigens die Kommas zwischen den Werten, aber das hast du sicherlich schon bemerkt.

    0
  • J

    @Nathan:
    Aber ich brauche ja den Wert 0x0001 und nicht 1 oder ist das egal?

    @SeppJ:
    Danke, muss jetzt erstmal deinen Post komplett lesen, und nein, hatte es noch nicht gemerkt, hatte die komplett vergessen, ich editiers grad

    0
  • Mod

    Wie viel ist denn 0x0001, wenn du es als Dezimalzahl schreibst?

    0
  • J

    Ok, ja das wird mir jetzt auch klar ^^

    Dann könnte ich doch auch schon vorher als ich noch #define verwendet habe, nur 1 schreiben. Habe das mit den Farben von irgendner Seite, die auf Google war. Da stand das mit dem 0x0001

    EDIT: Und seit wann gibt es C++ 11? Ich nutze Visual Studio 2008

    EDIT2: Und kommen bei enumeratoren dann nach 9 auch a,b,c usw?

    EDIT3: Und wie würde ein typedef für ein 2 Dimensionales Array aussehen?
    Habe das eben gegoogled, kam aber auf Schwachsinn, der nicht funktioniert hat 😃
    :

    typedef array<array<int, d_array;

    So leicht geht das dann doch nicht, oder? ^^
    Ich habe auch von typedef mit Parameter gelesen, ich muss warscheinlich solche nehmen, oder?

    Und wie teile ich Programmcode auf mehrere Dateien auf?
    Das wurde mir ja auch am Anfang geraten.

    Könnte mir bitte jemand all diese Fragen beantworten? Danke 😉

    0
  • J

    @asdfsdf:

    Bei deinem code für die Koordinatenverarbeitung bekomme ich die Meldung, dass tolower kein Element von std ist.

    und @ Mods: Sry für Doppelpost. Aber sonst hätte nie jemand den Post gesehn, wenn ich nur editiert hätte.

    0
  • N

    jkhsjdhjs schrieb:

    Bei deinem code für die Koordinatenverarbeitung bekomme ich die Meldung, dass tolower kein Element von std ist.

    #include <cctype>

    0
  • J

    Danke, funktioniert perfekt 😉

    0

  • Für globale Funktionen (ohne Klassen) kannst du dich ersteinmal an http://www.mikrocontroller.net/articles/Funktionen_auslagern_(C) halten.
    Wichtig ist ein Verständnis von Headerdateien zu erhalten.

    0
  • J

    Ok, Danke. Ich verstehe jetzt wie man ein Programm in mehrere Dateien aufteilt. Was ich aber immer noch nicht weiß ist, was es mir bringt, wenn ich das Programm aufteile?

    0

  • Stichwort: Modularität

    Wenn du beispielsweise die interne Spiellogik von der Ein- und Ausgabe getrennt hast, dann könntest du irgendwann einfach diese Spiellogik-Dateien nehmen und statt der Konsole ein Projekt mit einer Windows-GUI erstellen.
    Außerdem gibt es eine Richtlinie, daß einzelnen Dateien nicht größer als ca. 1000 Zeilen groß sein sollten (damit man noch einen Überblick darüber hat).

    P.S. Ich muss sagen, dein Code hat mich sehr an meine ersten BASIC Programme erinnert (auf dem C16 bzw. C64) - trotz C++. Und daher verstehe ich auch, warum es für Anfänger einfacher ist mit Imperative Programmierung zu beginnen (und so zu denken) als gleich mit objektorientierter Programmierung (und Denkweise).
    Als nächsten Schritt solltest du deinen Code in kleinere Funktionen unterteilen (am besten gleich so, daß du Eingabe, Verarbeitungsfunktionen (Spiellogik) und Ausgabe getrennt hältst).
    Und viele deiner bisherigen Codezeilen lassen sich stark vereinfache. Laß einfach den Computer für dich rechnen, anstatt selber, z.B. deine switch-case-Anweisungen:

    Pair Koordinatenverarbeitung(int x, int y) // oder besser char x, char y
{
  int x1 = 0;

  if (x >= 'A' && x <'Z')
    x1 = 10 * (x - 'A' + 1);
  else if (x >= 'a' && x <'z')
    x1 = 10 * (x - 'a' + 1);

  // ähnliches für y
  // ...
}

    (oder zusätzlich noch toupper() bzw. tolower() verwenden, damit man nur einmal die Formel hinschreiben braucht)

    Oder deine AppData-Zuweisung zu

    strcpy(&appdata[i], "\\C++ Schiffe versenken\\Optionen.cfg");

    usw...

    Viel Spaß und Erfolg weiterhin.

    0
Anmelden zum Antworten