relative Datei angaben
-
@Ichwerdennsonst sagte in relative Datei angaben:
Wenn ich jetzt dann wirklich mal genau zwei Ordner nach oben muss, kann ich dann ..\\..\\ schreiben?
Wenn es dir reicht dass es auf Windows funktioniert, dann ja. Wenn es auch auf anderen Systemen laufen soll solltest du besser
../../
verwenden.
-
@Ichwerdennsonst Mach doch die Eingabeaufforderung auf und spiele mit den Befehlen (z.B. cd, dir, type) rum
Es gibt auch ein Windows-Subsystem für Linux.
Damit kann man unter Windows Linux-Programme starten.
(der gcc ist auch nur ein Programm)Da ist auch eine Konsole/Terminal mit einer Shell dabei.
Erste Informationen unter https://de.wikipedia.org/wiki/Windows-Subsystem_für_Linux
-
@hustbaer Naja, es soll einfach Systemunabhänig sein oder von meiner Ordnerstruktur abhängig
-
Jedenfalls funktioniert das immer noch nicht
// 12345.cpp: Definiert den Einstiegspunkt für die Anwendung. // #include "12345.h" #include <fstream> using namespace std; int main(int argc, char* argv[]) { ifstream Datei{"../Textdateien/daten1.txt"}; string n{}; if (Datei) { Datei >> n; cout << "Datei:" << n << endl; } return 0; }
Die Dateistruktur ist folgende:
12345
->12345
->->12345.cpp
->Textdateien
->->daten1.txt
Gebe ich den vollständigen Pfad bis zum Laufwerk an funktioniert es ohne Probleme.
In dem Fall:
C:\Users\Tim\source\repos\12345\Textdateien\daten1.txt
-
Relative Pfade (die zur Laufzeit ausgewertet werden) sind relativ zum aktuellen Arbeitsverzeichnis, nicht zum Source-Verzeichnis. Je nachdem, aus welchem Verzeichnis du dein Programm also startest, wird es mal funktionieren und mal nicht.
-
Ok Danke!
-
Hallo,
Wenn es systemunabhängig werden soll must du auch auf die Zeichencodierung achten. Solange du bei Zeichen aus der ersten Seite der ASCII Page bleibst ist das kein Problem, sonst aber doch. Windows verwendet ja Codepage bzw. Unicode bei den passenden Funktionen. Bei Linux wäre es UTF8. Da musst du dich auf ein Verfahren einigen und bei Bedarf konvertieren.
-
@Braunstein sagte in relative Datei angaben:
Solange du bei Zeichen aus der ersten Seite der ASCII Page bleibst ist das kein Problem
Falls du damit die Zeichen 0...127 meinst: mehr gibt es in ASCII nicht
-
@hustbaer
Ok, dann eben. Solange du ASCII Zeichen verwendest.
Besser so?
-
-
@hustbaer
Gut. Das sollte es dann aber sein.
-
@Braunstein
Ich denke ja
-
Man könnte noch anmerken, dass relative Pfade zumindest unter Windows nicht mehr funktionieren müssen, selbst wenn man keine einzige Zeile Code diesbezüglich selber geschrieben hat.
Sei es durch eine Drittbibliothek, die einen Openfilename-Dialog öffnet (ohne das entsprechende Flag gesetzt zu haben) oder dass das Programm über eine Verknüpfung gestartet wurde, bei der „Ausführen in...“ -Ordner ein anderer als der ist, in der die Anwendung liegt.
Bei einigen Anwendungen mag das vielleicht egal sein, allerdings sollte man das schon im Hinterkopf haben.
-
@yahendrik
Relative Pfade funktionieren super auf Windows. Was du beschreibst hat nichts mit dem "nicht funktionieren" von relativen Pfaden zu tun, sondern damit dass relative Pfade eben relativ sind, und das Working-Directory nicht immer das selbe sein muss.
Das ist auch nicht Windows-spezifisch. Das selbe "Problem" hast du auf allen Betriebssystemen. Denn auch auf anderen Systemen werden relative Pfade relativ zum Working-Directory interpretiert und nicht relativ zum Executable.Der einzige (mir bekannte) Unterschied ist dass es auf Windows nicht immer möglich ist einen relativen zu X mit Basis (Working-Directory) Y zu bilden. Nämlich dann wenn die Pfade von X und Y unterschiedliche Laufwerksbuchstaben verwenden.
-
@yahendrik sagte in relative Datei angaben:
oder dass das Programm über eine Verknüpfung gestartet wurde, bei der „Ausführen in...“ -Ordner ein anderer als der ist, in der die Anwendung liegt.