if-Bedingung wird nie wahr

DocShoe

Es gibt tatsächlich einen Grund using namespace std nicht zu verwenden, nämlich Mehrdeutigkeiten zu vermeiden bzw. Eindeutigkeiten zu erzwingen. In cpp Dateien kann man das machen, in Header Dateien allerdings nicht.

Du bist Opfer deines eigenen Programmierstils geworden. Statt sich einen sauberen Stil anzueignen hast du vermutlich drauflosprogrammiert, ohne dir vorher Gedanken über Design und Strutur zu machen. Jetzt bist du an einem Punkt angekommen, wo das alles über dich hereinbricht und du den Überblick verloren hast. Natürlich ist ein Refactoring langwierig, aber da wirste wohl nicht drum rumkommen.

Du programmierst seit 20 Jahren C++? Oha.... Wie kann es dann sein, dass du Code wie yip produzierst? Und nichts über die STL weisst? Und nicht weisst, wie man einen Debugger bedient? Du hast im Diskussionsverlauf gefragt, ob yip eine Nummer zu groß ist? Mit den Informationen, die du gerade lieferst lautet die Antwort: Eindeutig ja.

Dein ganzes Projekt besteht aus 2 Dateien (yip.cc und yip_classes.h), in denen du, so leider muss ich ehrlich sein, unwartbaren Spaghetticode implementierst. Da ist überhaupt nichts modularisiert, wenigstens das hätte ich bei dem Ehrgeiz, einen ImageMagick Klon zu schaffen erwartet.
yip ist ein gutes Beispiel dafür, wie man´s nicht machen sollte, hier werden so gut wie alle guten Richtlinien verletzt.

Edit:
Um wenigstens etwas Konstruktives beizutragen:

teile deinen Code in Header- und Implementationsdateien auf. Als Faustregel: pro Dateipärchen eine Klasse.
richte dich nach der Faustregel "Eine Funktion - Eine Aufgabe". Schreibe viele kurze Funktionen statt eine lange. Funktionen über mehr als eine Bildschirmseite sollten die Ausnahme sein.
übergib Objekte per const-reference, wenn du nur lesend drauf zugreifst
deklariere Variablen so lokal wie möglich und vermeide globale Variablen. Hab´ keine Angst Objekte zu kopieren, heutige Compiler können Kopien häufig wegoptimieren
überlege dir sinnvolle Klassen zur Datenhaltung. Eine Klasse/Struktur für die Kommandozeilenparameter ist sinnvoll, besonders, wenn es sich um viele Parameter handelt. Lager das Parsing in eine eigene Funktion aus, die die Kommandozeile untersucht, ein Objekt passend befüllt und zurückgibt.
überfrachte Objekte nicht mit allen möglichen Methoden. Methoden, die ihre Aufgabe über das public interface eines Objektes durchführen können kann man als freie Funktionen implementieren
benutze die STL wo immer es geht. Ziehe STL Algorithmen und Lambdas handgeschriebenen Schleifen vor

hustbaer

@yadgar sagte in if-Bedingung wird nie wahr:

Nein, ernsthaft: seit ich in C++ programmiere (also seit ungefähr 20 Jahren) mache ich das so... ich habe mir auch mal versucht, die Bedienungsanleitung eines der gängigen Debugger durchzulesen - und bin schier verzweifelt!

Mit aktuellen grafischen IDEs geht das sowas von einfach. Solltest du echt nochmal probieren. Gibt sicher genügend YouTube Videos wo die ersten Schritte schön gezeigt werden.

Mechanics

Selbst an gdb sollte man nicht scheitern... Da liest man sich kurz ein und kann auch damit arbeiten.
Ich hab sogar schon mit dem DOS "debug" gearbeitet.

Mechanics

@yadgar sagte in if-Bedingung wird nie wahr:

Nein, ernsthaft: seit ich in C++ programmiere (also seit ungefähr 20 Jahren)

Es ist erschreckend... Erst dachte ich mir, ok, der muss ja alt sein. Aber jetzt ist mir eingefallen, viel weniger ist es bei mir auch nicht ^^

Yadgar

Hi(gh)!

@docshoe sagte in if-Bedingung wird nie wahr:

Es gibt tatsächlich einen Grund using namespace std nicht zu verwenden, nämlich Mehrdeutigkeiten zu vermeiden bzw. Eindeutigkeiten zu erzwingen. In cpp Dateien kann man das machen, in Header Dateien allerdings nicht.

Du bist Opfer deines eigenen Programmierstils geworden. Statt sich einen sauberen Stil anzueignen hast du vermutlich drauflosprogrammiert, ohne dir vorher Gedanken über Design und Strutur zu machen. Jetzt bist du an einem Punkt angekommen, wo das alles über dich hereinbricht und du den Überblick verloren hast. Natürlich ist ein Refactoring langwierig, aber da wirste wohl nicht drum rumkommen.

Ich würde sagen, bevor ich mich daran mache, arbeite ich erst mal den ganzen "Aupperle" ("Die Kunst der Programmierung in C++") durch, mein Problem ist, dass ich bis jetzt bei der Programmiererei nie ausdauernd und diszipliniert genug bei der Sache war, sondern mich nur sporadisch mal alle paar Monate mit der Materie beschäftigt habe...

Du programmierst seit 20 Jahren C++?

Sagen wir besser, ich dilettiere seit 20 Jahren in C++ herum... in POV-Ray ist es auch nicht besser, da passieren mir bis auf den heutigen Tag Anfängerfehler, während die Cracks auf news.povray.org die komplexesten Szenen locker aus dem Ärmeln schütteln...

Oha.... Wie kann es dann sein, dass du Code wie yip produzierst? Und nichts über die STL weisst? Und nicht weisst, wie man einen Debugger bedient? Du hast im Diskussionsverlauf gefragt, ob yip eine Nummer zu groß ist? Mit den Informationen, die du gerade lieferst lautet die Antwort: Eindeutig ja.

Mir kommt es sogar oft so vor, dass das ganze Leben für mich mindestens eine Nummer zu groß ist...

Dein ganzes Projekt besteht aus 2 Dateien (yip.cc und yip_classes.h), in denen du, so leider muss ich ehrlich sein, unwartbaren Spaghetticode implementierst. Da ist überhaupt nichts modularisiert, wenigstens das hätte ich bei dem Ehrgeiz, einen ImageMagick Klon zu schaffen erwartet.
yip ist ein gutes Beispiel dafür, wie man´s nicht machen sollte, hier werden so gut wie alle guten Richtlinien verletzt.

Um wenigstens etwas Konstruktives beizutragen:

teile deinen Code in Header- und Implementationsdateien auf. Als Faustregel: pro Dateipärchen eine Klasse.

richte dich nach der Faustregel "Eine Funktion - Eine Aufgabe". Schreibe viele kurze Funktionen statt eine lange. Funktionen über mehr als eine Bildschirmseite sollten die Ausnahme sein.

übergib Objekte per const-reference, wenn du nur lesend drauf zugreifst

deklariere Variablen so lokal wie möglich und vermeide globale Variablen. Hab´ keine Angst Objekte zu kopieren, heutige Compiler können Kopien häufig wegoptimieren

überlege dir sinnvolle Klassen zur Datenhaltung. Eine Klasse/Struktur für die Kommandozeilenparameter ist sinnvoll, besonders, wenn es sich um viele Parameter handelt. Lager das Parsing in eine eigene Funktion aus, die die Kommandozeile untersucht, ein Objekt passend befüllt und zurückgibt.

überfrachte Objekte nicht mit allen möglichen Methoden. Methoden, die ihre Aufgabe über das public interface eines Objektes durchführen können kann man als freie Funktionen implementieren

benutze die STL wo immer es geht. Ziehe STL Algorithmen und Lambdas handgeschriebenen Schleifen vor

Was ist das, die STL? Was sind Lambdas? Bevor ich deine Ratschläge überhaupt verstehen kann, sollte ich wirklich erst mal richtig C++ lernen - und zwar nicht mit irgendwelchen aus dem Internet zusammengesuchten Informationskonfetti (dafür HASSE ich das Internet!), sondern ganz altmodisch mit einem vernünftigen Lehrbuch - wie eben etwa dem "Aupperle"!

Und wenn ich es danach immer noch nicht hinbekomme, bin ich wohl einfach zu dumm zum Programmieren... und sollte mich besser zum Tütenkleben in einer Behindertenwerkstatt anmelden!

Bis bald im Khyberspace!

Yadgar

Yadgar

Hi(gh)!

Habe mittlerweile meine alten C-Lehrbücher ausgegraben... und ich glaube wirklich, dass ich c64multicolor_correct() besser überwiegend in C schreibe (bzw. das erstmal sogar als eigenständiges Programm, um besser testen zu können)... da C 64-Bilder (GEOS mal außen vor gelassen) sowieso immer 160 x 200 Pixel groß sind, sind Vektoren mit ihrer dynamischen Speicherverwaltung in diesem Fall reiner Overkill, also täte es auch ein eindimensionales Pixel-Array, wo man die Pixelpositionen im Bild mit Integer- und Modulo-Divisionen errechnet...

Bis bald im Khyberspace!

Yadgar

Yadgar

Hi(gh)!

Überlegungen vorweg:

Für Pixel bzw. Farben wird weiterhin eine dreiteilige Struktur verwendet:

struct rgb { short red; short green; short blue; };

Wobei, schlanker wäre ja unsigned char... was haltet Ihr davon? Bei Testausgaben müssten die Farbwerte dann natürlich explizit in short gewandelt werden, aber sonst sehe ich da keinen Nachteil... oder?

Da der Datenbestand des C 64-Bildes zwischen mehreren Funktionen (loadTGA(), c64multicolor_correct() und saveTGA()) ausgetauscht und in der zweitgenannten auch verändert wird, muss das rgb-Array im Hauptprogramm bekannt sein:

rgb c64image[32000];

und wird per Referenz (Referenz auf Zeiger!) übergeben:

bool loadTGA(rgb(&*), string); 
void c64multicolor_correct(rgb(&*));
bool saveTGA(rgb(&*), string);

Bis bald im Khyberspace!

Yadgar

Swordfish

@yadgar sagte in if-Bedingung wird nie wahr:

wird per Referenz (Referenz auf Zeiger!) übergeben

Wozu soll das gut sein?