Linkerfehler
-
Du willst also keine Hilfe. Bitte schließen.
-
Danke hat geholfen.
-
Was fehlt euch hier auf?
- Nutzung von globalen Variablen anstelle von Konfigurationsobjekten
- Konstaten als Präprozessor-Makros anstelle von const
- Nicht Verwendung von Initalisierungsliste
- #pragma once anstelle von Include guardPasst zwar nicht zum Problem
-
Zeus schrieb:
Was fehlt euch hier auf?
- Nutzung von globalen Variablen anstelle von Konfigurationsobjekten
- Konstaten als Präprozessor-Makros anstelle von const
- Nicht Verwendung von Initalisierungsliste
- #pragma once anstelle von Include guard1. Konfigurationsobjekten sind mir unbekannt.
2. Hier nehem ich die mit Absicht, weil die meiner Meinung nach besser sind. Welchen Vorteil haben deiner Meinung nachconsts?
3. Wo sollte ich den die Liste verwenden?
4. Ist mir auch unbekannt
-
Die erinnerung schrieb:
2. Hier nehem ich die mit Absicht, weil die meiner Meinung nach besser sind. Welchen Vorteil haben deiner Meinung nach
constsIn erster Linie Typsicherheit und man umgeht dabei die gängigen Probleme, die bei unachtsamer Verwendung des Präprozessors auftreten können. Welche das sind, sagt dir Google oder besser ein gutes Lehrbuch.
Die erinnerung schrieb:
3. Wo sollte ich den die Liste verwenden?
Ist das jetzt dein Ernst? Du bist nich in der Lage die Verwendung von Initialisierungslisten im Kontext von C++-Konstruktoren nachzuschlagen, willst aber D3D-Code schreiben?
Die erinnerung schrieb:
4. Ist mir auch unbekannt
Über die grundsätzliche Bedeutung der Präprozessor-Direktive "#pragma" bist du dir aber bewusst? Insbesondere darüber, dass ein Compiler nicht verpflichtet ist, die damit gegebenen Anweisungen zu kennen? Der übliche und überall funktionierende Weg das Einbinden eines Headers idempotent zu machen, sind Include-Guards:
#ifndef PRAEPROZESSOR_SYMBOL #define PRAEPROZESSOR_SYMBOL <Inhalt des Headers> #endifWas könnte das wohl machen? Es gibt übrigens auch recht brauchbare kostenlose Ebooks, mit denen man Programmieren und C++ lernen kann. Da steht sowas alles drin.
-
Achso, das mit den Iclude Guards kannte ich. Aber ich verwende Mircosoft Visual C++ Express und ich weiß, dass der das richtig interpretiert.
Und die eigentliche Bedeutung von
#pragmaist mir nicht bekannt. ich habe bis her nur ein Anfängerbuch gelesen. Den Rest learning by doing. Von daher habe ich noch große Lücken.
-
Die erinnerung schrieb:
Achso, das mit den Iclude Guards kannte ich. Aber ich verwende Mircosoft Visual C++ Express und ich weiß, dass der das richtig interpretiert.
Kein Grund, nichtportablen Code zu schreiben. Viele Compiler können das zwar, aber viel Spaß, wenn du dann doch irgendwann deinen Code auf einen Compiler portieren möchtest, der das nicht unterstützt. Plötzlich darfst du dann ein paar tausend include-Guards nachreichen...
Wenn du mit dem Anfängerbuch durch bist, steht als nächstes "Effective C++" von Scott Meyers an, der erklärt auch warum Makros pfui sind
-
Danke für den Buchtipp.
Nur ich habe wirklich nicht vor (ich habe bis gerade eben nicht mal daran gedacht) den Compiler zu wechseln.
Und falls doch, dann wäre das ja wohl mein Problem, oder?
Aber hier würde ich sagen: Never change a running system.
-
Die erinnerung schrieb:
Nur ich habe wirklich nicht vor [...] den Compiler zu wechseln.
Noch
Als Anfänger hat das niemand vor. War auch alleits nur ein gutgemeinter Ratschlag.Die erinnerung schrieb:
Und falls doch, dann wäre das ja wohl mein Problem, oder?
Das ist grundsätzlich alles, was du bei deinen ersten Gehversuchen in der Programmierung machst. Wie gesagt, nur ein gut gemeinter Ratschlag...
Die erinnerung schrieb:
Aber hier würde ich sagen: Never change a running system.
Dann fix den Linkerfehler und ändere nichts mehr an dem Programm, sobald es läuft
-
Ich bin sicher du weißt, was ich meine, falls nicht würde ich mir Sorgen machen. Aber danke für den Tipp, ich werde vielleicht darüber nachdenken, darüber nachzudenken ihn zu verwenden.
Nein, jetzt mal im Ernst:
Wenns mir Probleme macht, dann ändere ich es.