Je cherche à manipuler des chemins de fichiers plus longs dans mon application Windows.
Actuellement, j'ai une zone de texte (zone d'édition) dans laquelle un utilisateur peut taper un chemin de fichier absolu. Je lis ensuite ce chemin de fichier dactylographié, en utilisant évidemment, ici je ' m Compte sur le ou y a-t-il une meilleure façon? Puis-je utiliser une matrice de longueur variable? ( Merci d'avoir avancé! Voici tout ce que j'ai mentionné ci-dessus: getwindowtext , dans une chaîne déclarée comme: TCHAR FilePath [max_path]; max_path constante qui limite-moi à 260 caractères. Donc, pour gérer des noms de fichiers / chemins plus longs pourrais-je étendre mon tableau TCHAR comme ceci: TCHAR FilePath [32767]; . TCHAR FilePath []; est-ce même possible en C ++? - Désolé je suis assez nouveau à ceci).
3 Réponses :
Non, car si vous obtenez un chemin plus long, Windows ne peut pas l'accepter. Donc, bien que techniquement, vous pouvez conserver plus de caractères que dans votre mémoire tampon, vous ne pouvez jamais utiliser le résultat du fichier FilePath.
Il existe un certain nombre de limitations par rapport aux chemins de fichiers sous Windows. Par défaut, les chemins ne peuvent pas dépasser 260 caractères, ce que le Cependant, vous peut accès aux chemins plus longs - avec certaines limitations - en préfixant le chemin avec "\\? \". Cependant, les limitations d'utilisation du préfixe "\\? \" L'emportent généralement sur l'avantage:
Pour être honnête, le point n ° 2 est le vrai tueur: vous vous ouvrez à toutes sortes de problèmes lors de l'utilisation du préfixe "\\? \" et que vous devez essentiellement ré-implémenter les règles de canonicalisation Win32 vous-même si vous allez. cette route.
Par conséquent, ma recommandation est de coller avec la limitation 260. Au moins jusqu'à ce qu'il y ait une meilleure prise en charge de la plate-forme pour des chemins plus longs. max_path constante est pour.
LoadLibrary échouera toujours sur un chemin de plus de 260 caractères)
Merci pour le conseil. Je pense que je vais suivre votre recommandation!
Pour # 2, notez que GetfletLPathNameW effectue cette canonicalisation pour vous et est pas < / B> Limité à max_path, sauf si vous spécifiez que la taille de la mémoire tampon. (Préfixez le chemin avec \\ \ \ \ après appeler getfletlpathname.) Quelques mises en garde restantes: 1) Les chemins UNC doivent utiliser \\? \ Unc \ à la place de \\. 2) Des dispositifs DOS tels que NUL ou SOMEDIR \ NUL sont convertis en \\. \ Nul, mais \\. \ Ne fonctionne pas partout (et \\? \ \ \ \ \ Nul est autre chose entièrement). 3) \\? \ C: \ nul peut créer un fichier difficile à traiter.
Cela dépend du type de programme que vous écrivez. Ma propre stratégie a généralement été de restreindre la voie la création à max_path en longueur, mais être en mesure de lire les données existantes à partir de chemins plus longs (en utilisant le préfixe "\\?" Prefix Dean mentionne dans sa réponse). Il y a des exceptions à ce que, tout comme par exemple, un programme de sauvegarde doit accepter de longues chemins et reproduire exactement ce qu'il a été donné comme entrée.
tandis que Dean est certainement correct que Windows ne canonicalise pas des chemins plus longs pour vous, je n'ai pas trouvé cela pour être une grande préoccupation en règle générale. Cela ne signifie généralement pas écrire votre propre code pour canonaliser le chemin, ce qui signifie généralement que l'utilisateur entrait dans des chemins d'une manière qui ne génère simplement pas de telles choses en premier lieu.
C'est exactement le but de
max_path - vous ne pouvez pas avoir de chemins plus longtemps que cela.@casablanca Il peut toutefois être une bonne idée de le déclarer avec Max_Path + 1 pour le caractère final '\ 0'.
@Luiscabal: Je viens de vérifier MSDN Et il ressemble à max_path inclut le terminateur null.