Warum springt er nicht in die while-schleife?

[J. T. (chaoskind)]

MoinMoin,

angefangen hat das ganze so:
Beitrag "zufallsabhängig eine Anzahl von Instanzen? eines Structs erstellen"

das mit dem malloc und realloc hab ich erstmal zur Seite gelegt.

Weiter ging es dann so:
Beitrag "Probleme Grafiklibrary allegro zum laufen zu bekommen"

inzwischen hab ich es in DevC++ zum laufen bekommen, aber der Editor ist 
für mich irgendwie die Hölle. Wenn ich in CodeBlocks auf die selben 
Dateien verweise und dem Linker die selbe Datei zum linken gebe, klappt 
es immer noch nicht. Das nervt mich dezent, ich mag den Editor von 
CodeBlocks sehr gerne. Falls da noch wer nen Tipp hätte, gerne her 
damit.

Nun aber zum eigentlichen Problem. Gibt es einen offensichtlichen Grund, 
warum er nicht in die while-schleife springt?

void HasenBewegen(sHase *HasenPt, unsigned *HCntPt, sFuchs *FuchsPt, unsigned *FCntPt, sFeld *SpielfeldPt)
{
  unsigned x = 0;
  unsigned y = 0;
  unsigned i = 0;
  unsigned GhAkt = 0;  //Höhe des Rasens auf dem Feld auf dem der aktuell betrachtete Hase sitzt
  
  printf("Der HasencounterPointer sagt, es gibt %u Hasen\n", *HCntPt);
  
  while(i < (*HCntPt) );
  {
    x = HasenPt->PositionX;
    y = HasenPt->PositionY;
    GhAkt = (SpielfeldPt + (x * SpielfeldgroesseX)+y)->Grashoehe;
    printf("Grashoehe auf Feld X: %u Y: %u ist %u\n", x, y, (SpielfeldPt + (x * SpielfeldgroesseX)+y)->Grashoehe);
    i++;
    HasenPt++;
  }
  
  printf("nach der Schleife\n");
}

die printf sind nur als debug ausgaben gedacht. Der HasenCounterPointer 
erzählt mir noch fröhlich (und korrekterweise) dass es 100 Hasen gibt. 
Dann ist einfach Ruhe im Karton, kein beenden mit negativen 
Return-Werten, kein Absturz, kein normales beenden. Es passiert einfach 
nix mehr.
i wird mit 0 initialisiert, der Hasenpointer zeigt auf ne Stelle, an der 
100 steht. i ist also kleiner als *HCntPt, somit sollte die Schleife 
doch eigentlich ausgeführt werden?

mit leicht verständnisslosen Grüßen,
Chaos

[J. T. (chaoskind)]

P.S.
selbst wenn ich statt "while(i<*HCntPt)" "while(i<100)" schreibe, tut 
sich nix.

[Oliver S. (oliverso)]

J. T. schrieb:
> while(i < (*HCntPt) );

Die Schleife läuft seeeeeeeehr lange...

Oliver

[Hannes J. (hannes_j)]

while(); ich vermute du musst das Semikolon wegnehmen.

[J. T. (chaoskind)]

Oooooohhh man, mal wieder mein "Lieblingsfehler". Ich danke euch, 
irgendwie hab ich für falsch gesetzte/fehlende Semikollabierte ne echt 
hartnäckige Betriebsblindheit entwickelt :D

[Schlaumaier (Gast)]

J. T. schrieb:
> Oooooohhh man, mal wieder mein "Lieblingsfehler". Ich danke euch,
> irgendwie hab ich für falsch gesetzte/fehlende Semikollabierte ne echt
> hartnäckige Betriebsblindheit entwickelt :D

Ist der Grund warum ich C hasse. Zu viel unnötige Tipperei.

[pnp (Gast)]

Schlaumaier schrieb:
> Zu viel unnötige Tipperei.

Ein Semikolon. Alles klar...

[Schlaumaier (Gast)]

pnp schrieb:
> Ein Semikolon. Alles klar...

Ein Semikolon was man gerne übersieht, und dann Stundenlang sucht, weil 
wie der TO gerade bewiesen hat KEIN Fehler auslöst.

Ich hatte zu C=64 Zeiten, mal 2 Tage Data-Zeilen abgetippt und dabei 1 
Komma zu viel eingeben.  Die Poke-Schleife hat da eine NULL gesehen und 
den HEX-Code versaut.

Ich habe sogar beim Verlag angerufen ob da Tippfehler sind im Code (was 
nicht unüblich war).

Erst meine Schwester (0 Ahnung von Codes) hat das gefunden, als sie den 
Code der Zeitung mit mein Getippe verglichen hat.

Seit dem Hasse ich so Sachen. Da sucht man sich tot dran.

P.s.: Die Zeitung hatte danach ein Programm entwickelt das mit 
Prüfsummen bei der Eingabe das Tippen kontrollierte.

[A. S. (Gast)]

Schlaumaier schrieb:
> Ich hatte zu C=64 Zeiten, mal 2 Tage Data-Zeilen abgetippt und dabei 1
> Komma zu viel eingeben.

Seitdem gibt es Warnungen, nicht nur Fehler.

[Schlaumaier (Gast)]

A. S. schrieb:
> Seitdem gibt es Warnungen, nicht nur Fehler.

OK.

Das heißt logischerweise  der TO kann keine Warnungen lesen, bzw, hat 
sie nicht gelesen ODER er hat keine bekommen, weshalb er hier nachfragt.

[Rolf M. (rmagnus)]

Schlaumaier schrieb:
> J. T. schrieb:
>> Oooooohhh man, mal wieder mein "Lieblingsfehler". Ich danke euch,
>> irgendwie hab ich für falsch gesetzte/fehlende Semikollabierte ne echt
>> hartnäckige Betriebsblindheit entwickelt :D
>
> Ist der Grund warum ich C hasse. Zu viel unnötige Tipperei.

Hä? Hier hätte er weniger tippen müssen, damit es geht.

Schlaumaier schrieb:
> Ich hatte zu C=64 Zeiten, mal 2 Tage Data-Zeilen abgetippt und dabei 1
> Komma zu viel eingeben.  Die Poke-Schleife hat da eine NULL gesehen und
> den HEX-Code versaut.

In C?

Schlaumaier schrieb:
> A. S. schrieb:
>> Seitdem gibt es Warnungen, nicht nur Fehler.
>
> OK.
>
> Das heißt logischerweise  der TO kann keine Warnungen lesen, bzw, hat
> sie nicht gelesen ODER er hat keine bekommen, weshalb er hier nachfragt.

Oder er hat sie nicht eingeschaltet. gcc warnt bei sowas:

int main()
{
    int i = 0;
    while (i < 100);
    {
        i++;
    }
}

Ausgabe von gcc bei aktivierten Warnungen:
kaputtelooop.c: In function ‘main’:
kaputtelooop.c:4:5: warning: this ‘while’ clause does not guard... [-Wmisleading-indentation]
    4 |     while (i < 100);
      |     ^~~~~
kaputtelooop.c:5:5: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘while’
    5 |     {
      |     ^

[jo (Gast)]

Oliver S. schrieb:
>> while(i < (*HCntPt) );
>
> Die Schleife läuft seeeeeeeehr lange...

Keiner versteht dich...
Vielleicht, weil keiner mehr beim Lesen mit denkt?

[J. T. (chaoskind)]

Schlaumaier schrieb:
> Das heißt logischerweise  der TO kann keine Warnungen lesen, bzw, hat
> sie nicht gelesen ODER er hat keine bekommen, weshalb er hier nachfragt.

Der TO hat keine Warnung bekommen. Fehler- und Wsrnungslos wurde 
kompiliert.

Allerdings weiß ich aufgrund von Unkenntnis der IDE nicht, wo ich das 
Einstell.

[Schlaumaier (Gast)]

J. T. schrieb:
> Allerdings weiß ich aufgrund von Unkenntnis der IDE nicht, wo ich das
> Einstell.

HM.  einfach mal die IDE / Sprache sagen. Vielleicht weiß ja einer hier 
wie es geht. Spart Stress beim nächsten pösen Semikolon. fg

[J. T. (chaoskind)]

Die IDE ist DevC++, die ich nur nutze, weil ich den ganzen Krams in 
CodeBlocks, dessen Editor ich sehr mag, nicht zum laufen bekomme obwohl 
ich die selben Dateien/Ordner angebe, wie im elenden DevC++. Steht alles 
im 2ten verlinkten Beitrag im Eröffnungspost.

[mein Name ist Hase, ich weiß von Nichts (Gast)]

J. T. schrieb:
> angefangen hat das ganze so:

Also wird bei dir die Anzahl der Hasen mal größer und mal kleiner (wenn 
diese gefressen werden). Und die Hasen sind dann Instanzen einer 
Struktur.

Dann musst du mit den verketteten Listen arbeiten. Im Prinzip kannst 
jedes Beispiel dazu aus dem Netz nehmen und erweitern 
(Haseneigenschaften hinzufügen). Wie neue Einträge hinzugefügt werden, 
steht in jedem Tutorial zu dieser Datenstruktur (verkettete Liste).

Oder noch extremer. Man erzeugt ein Array maximaler Größe (meinetwegen 
SPALTENANZAHL*ZEILENANZAHL). Und arbeitet dann mit einem Counter, der 
angibt wieviele Hasen man tatsächlich auf dem Feld hat. Die anderen 
Arrayeinträge werden halt ignoriert. Ganz ohne malloc und Co..

[J. T. (chaoskind)]

mein Name ist Hase, ich weiß von Nichts schrieb:
> Oder noch extremer. Man erzeugt ein Array maximaler Größe (meinetwegen
> SPALTENANZAHL*ZEILENANZAHL). Und arbeitet dann mit einem Counter, der
> angibt wieviele Hasen man tatsächlich auf dem Feld hat. Die anderen
> Arrayeinträge werden halt ignoriert. Ganz ohne malloc und Co..

So mach ichs z Zt.

Dennoch würd ich das ganze gerne in CodeBlocks machen

[Daniel -. (root)]

J. T. schrieb:
> Die IDE ist DevC++, die ich nur nutze, weil ich den ganzen Krams in
> CodeBlocks, dessen Editor ich sehr mag, nicht zum laufen bekomme obwohl
> ich die selben Dateien/Ordner angebe, wie im elenden DevC++. Steht alles
> im 2ten verlinkten Beitrag im Eröffnungspost.

Tip. IDEs mal links liegen lassen und eine Affaire mit der Kommanozeile 
anfangen.

[Faulenzer (Gast)]

Typisch C/C++: Jeden Mist muss man extra einschalten, egal ob Warnungen 
oder Optimierungen, und ganz fies, viele Warnungen werden ohne 
eingeschaltete Optimierungen nicht gefunden.

C/C++ ist einfach nur Steinzeit. Viele andere Systeme machen es vor, wie 
man brauchbare Compiler baut inkl. Warnungen und Fehlermeldungen, die 
man auch versteht, wie z.b. bei Rust.

Wer sich freiwillig heute noch C/C++ antut ist Masochist. Wer es für 
Geld tut, ist doof wenn er nicht völlig unverschämte Preise aufruft.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

J. T. schrieb:
> Dennoch würd ich das ganze gerne in CodeBlocks machen

Dann hör auf zu jammern und bring deine IDE in Ordnung und unter 
Kontrolle.

Immer das Gleiche mit euch IDE-Fetischisten. Es muss unbedingt DIE EINE 
IDE sein. Dann stellt sich raus man ist mit ihr überfordert, versteht 
sie nicht, hat sie nicht unter Kontrolle und schafft es nicht sie zu 
konfigurieren. Dann wird wie ein verschmähter Liebhaber gejammert.

[A. S. (Gast)]

Hannes J. schrieb:
> Dann hör auf zu jammern und bring deine IDE in Ordnung und unter
> Kontrolle.

Es ist wie bei malloc bei ihm. Statt es auszuprobieren muss es gleich in 
ein (für ihn) komplexes,  Programm gewoben werden.

Hier das gleiche: statt einen halben Tag ein hello world auf 2 Dateien 
erweitern, mit Headern, build und debug, wird gleich das ganze Projekt 
kopiert.

Es sind ja nicht nur die fehlenden Warnungen: sowohl mit Debugger als 
auch mit printf-ausgaben wäre der Fehler innerhalb von 3 oder 4 
itterationen lokalisiert.

[Rolf M. (rmagnus)]

A. S. schrieb:
> Hier das gleiche: statt einen halben Tag ein hello world auf 2 Dateien
> erweitern, mit Headern, build und debug, wird gleich das ganze Projekt
> kopiert.

Ja. In der Programmierung gilt ganz besonders das Prinzip "teile und 
herrsche", also das Problem soweit zu unterteilen, dass man jeden Teil 
davon überschauen und einzeln lösen kann.