Maximale Länge eines Pfades. (Programmierkonventionen)
-
Hallo Forum,
da ich den Pfad meiner eigenen Anwendung nicht zuverlässig über args[0] herausbekomme benutze ich jetzt GetModuleFileName(). Dort muß man einen Buffer bereitstellen wo der Pfad hereingeschrieben wird. Im Internet ist der Buffer 256 Zeichen lang. Aber könnte der Pfad nicht viel länger sein?
Momentan habe ich eine Schleife die schaut ob der Buffer vollständig gefüllt ist und wenn ja GetModuleFileName erneut mit der doppelten Bufferlänge aufruft. Ist das so gedacht? (Ich stand des öfteren vor solchen Problemen)Eigentlich muß imm er die Funktion die den Speicher anfordert ihn auch wieder freigeben. Gibt es da auch Ausnahmen von der Regel oder sollte man sich daran strikt halten?
Vielen Dank
Peter
-
peterfarge schrieb:
Hallo Forum,
*Sieht ein Forum zurückwinken*
peterfarge schrieb:
Im Internet ist der Buffer 256 Zeichen lang. Aber könnte der Pfad nicht viel länger sein?
Im Internet? Du meinst die MSDN? Der Buffer muss 256 Zeichen lang sein, weil ein Pfad in Windows nicht länger als 256 Zeichen sein kann. Ich glaube du kannst schon mehr Speicher anfordern, es wäre nur sinnlos.
peterfarge schrieb:
Momentan habe ich eine Schleife die schaut ob der Buffer vollständig gefüllt ist und wenn ja GetModuleFileName erneut mit der doppelten Bufferlänge aufruft. Ist das so gedacht?
Wie es gedacht ist, steht in der MSDN. Dein Problem verstehe ich allerdings nicht so und auch nicht was das mit der doppelten Bufferlänge auf sich hat. Du kannst natürlich auch hier, bei deinem Freund und Helfer nachschauen, nämlich der FAQ: http://www.c-plusplus.net/forum/viewtopic-var-t-is-39131.html
peterfarge schrieb:
Eigentlich muß imm er die Funktion die den Speicher anfordert ihn auch wieder freigeben. Gibt es da auch Ausnahmen von der Regel oder sollte man sich daran strikt halten?
Normalerweise ist man für den Speicher, welcher man selber anfordert auch selber verantwortlich. Wenn was anderes wäre, dann würde das wohl explizit angegeben sein. Ein zusätzliches delete, obwohl schon eins getan wurde, schadte glaube ich allerdings auch nicht, ausser halt Rechenleistung ^^
Grüssli
-
Verwende doch das define MAX_PATH aus windef.h.
-
Grundsätzlich kann ein Pfad die Länge von _MAX_PATH (das ist nicht 256 sonder 260) überschreiten. In diesem Fall funktioniert aber z.B. keine der Shell Funktionien mehr. Diese sind alle auf _MAX_PATH ausgelegt. Auch beim Öffnen der Dateien muss CreateFile mit \?\ im Dateinamen verwendet werden.
Siehe Doku:
In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\?\" to the path. For more information, see Naming a File.In der gröberen Praxis sieht es so aus, dass die meisten Programme mit Pfaden >_MAX_PATH versagen und dies nicht unterstützen. Wie gesagt. Nicht mal der Explorer kann es.
Meine Programme auch nicht. Alle Pfade sind intern bei mir auf _MAX_PATH beschränkt!
-
Wenn der Buffer voll ist muß ein größerer angefordert werden und erneut versucht werden. So war meine Idee.
Das mit der Pfadlänge ist komisch. Wenn man einen "langen" Pfad erstellt kürzt ihn Windows. In diesem Ordner kann man dann nicht mal mehr eine Datei erstellen. Erst wenn man diesen Ordner mit subst.exe auf ein anderes Laufwerk mapped kann man weitere Ordner erstellen. Da dann der Pfad unter C: länger als 255 (oder 260) Zeichen ist kann man von C: aus nicht mehr auf diesen Ordner zugreifen.
Das ist sicher eine effiziente Art Dateien vor der Schwester zu verstecken*g*
Aber gut das ich dieses Schleifenkonstrukt jetzt wegwerfen kann...Vielen Dank
