Должен ли я иметь дело с файлами длиннее, чем MAX_PATH?
Стандарт C ++ требует определения для вашего статического члена константы, если определение каким-то образом необходимо.
Требуется определение, например, если используется его адрес. push_back принимает свой параметр с помощью ссылки const, и поэтому строгому компилятору нужен адрес вашего члена, и вам нужно определить его в пространстве имен.
Когда вы явно используете константу, вы создаете временное, и это временное, которое связано с ссылкой (по специальным правилам в стандарте).
Это действительно интересный случай, и я на самом деле думаю, что стоит подняться вопрос, чтобы std был изменен на имеют одинаковое поведение для вашего постоянного члена!
Хотя, в каком-то странном виде это можно рассматривать как законное использование унарного оператора «+». В основном результат unary + является rvalue, поэтому применяются правила привязки rvalues к ссылкам const, и мы не используем адрес нашего статического члена const:
v.push_back( +Foo::MEMBER );
4 ответа
Ваши собственные API-интерфейсы не должны жестко устанавливать фиксированный предел длины пути (или любые другие жесткие ограничения); однако не следует нарушать предварительные условия системных API-интерфейсов для выполнения некоторых задач. IMHO, тот факт, что Windows ограничивает длину имен путей, абсурден и должен считаться ошибкой. Тем не менее, нет, я бы посоветовал вам не пытаться использовать различные системные API-интерфейсы, отличные от задокументированных, даже если это приводит к определенному нежелательному поведению, например ограничению максимальной длины пути. Короче говоря, ваше мнение совершенно справедливо; если ОС не поддерживает его, значит, ОС не поддерживает его. Тем не менее, вы можете дать понять пользователям, что это ограничение Windows, а не вашего собственного кода.
Как вы упомянули, многие функции оболочки Windows работают только с путями до MAX_PATH. Я считаю, что Windows XP и Vista имеют проблемы в проводнике при вложении каталогов с длинными именами файлов. Я не проверял Windows 7 - возможно, они это исправили. К сожалению, это означает, что пользователям сложно просматривать этот файл.
Если вы действительно хотите поддерживать длинные пути, вам необходимо проверить все функции, которые вы используете в Shell32.dll, которые принимают пути, чтобы убедиться, что они поддерживают длинные пути. Для тех, кто этого не делает, вам придется писать их самостоятельно, используя функции Kernel32.
Если вы решите использовать Shell32 и ограничитесь MAX_PATH, было бы целесообразно написать код для поддержки длинных путей к файлам. Если позже Microsoft изменит Shell32 (или создаст альтернативу), у вас будет больше возможностей добавить для них поддержку.
Просто чтобы добавить еще пару аспектов к проблеме, помните, что имена файлов - UTF-16, и вы можете столкнуться с файловыми системами, отличными от NTFS или FAT, которые могут быть чувствительны к регистру!
Это ограничение заложено в множество программ, написанных на C или C++. Включая код MSFT, хотя они и пытаются его устранить. Это только частично ограничение Win32, у него все еще есть жесткий верхний предел на длину имени файла (не пути), например, через WIN32_FIND_DATA. Одна из причин, по которой даже .NET имеет ограничения на длину. Это не пройдет в ближайшее время, Win32 все еще сильна, и строка C не исчезнет.
Ваш клиент, несомненно, будет мало сочувствовать этому, возможно, до тех пор, пока вы не покажете ему другую программу, которая не работает точно так же. Однако убедитесь, что ваш код надежно обнаруживает потенциальное переполнение буфера строки, после чего проводится разумная диагностика. Никакого сочувствия к программам, бомбящимся на повреждении кучи.
Это не настоящая проблема. NTFS поддерживает имена файлов до 32K (32,767 широких символов). Вам нужно только использовать правильный API и правильный синтаксис имен файлов. Основное правило: имя файла должно начинаться с '\\\?\' (см. http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx), например \\\?\C:\Temp. Тот же синтаксис вы можете использовать с UNC: \\\?\UNC\Server\share\Path. Важно понимать, что вы можете использовать только небольшое подмножество функций API. Например, посмотрите на описание функций в MSDN
CreateFile
CreateDirectory
MoveFile
и так далее
вы найдете текст вроде :
В ANSI версии этой функции, имя ограничено MAX_PATH символов. Чтобы расширить это ограничение до 32 767 символов, вызовите Unicode версию функции и добавьте "\?\" к пути. Для получения дополнительной информации см. в разделе Именование файла.
Эти функции вы можете безопасно использовать. Если у вас есть хэндл файла от CreateFile, вы можете использовать все остальные функции, используемые hFile (ReadFile, WriteFile и т.д.) без каких-либо ограничений.
Если вы пишете программу, например, сканер вирусов или программу резервного копирования, или какое-нибудь хорошее программное обеспечение, работающее на сервере, вы должны написать свою программу так, чтобы все файловые операции поддерживали имена файлов до 32K символов, а не MAX_PATH символов.