Code: |
HANDLE __stdcall OpenArchive(tOpenArchiveData* ArchiveData) |
Mowgli wrote: |
Исходя из такой логики уникальность требуется исключительно между единовременно вызванными функциями плагина. Это могут быть даже не указатели, а скажем числа 0, 1, 2 и т.д. |
VadiMGP wrote: |
Непонятно что такое "единовременно вызванные функции плагина", но в принципе, ты логику описал верно. |
Mowgli wrote: |
А вот возможна ли ситуация, когда одновременно одним плагином распаковывается несколько разных архивов? |
Mowgli wrote: |
А вот возможна ли ситуация, когда одновременно одним плагином распаковывается несколько разных архивов? |
Worros wrote: |
это нарушение стандарта ТС |
VadiMGP wrote: |
Наверно можно создать такую ситуацию. В комбинации с WDX плагинами. |
Worros wrote: |
По-моему невозможна. ...это нарушение стандарта ТС. |
VadiMGP wrote: |
Лет пять назад он даже согласился и пообещал добавить этот бит.
Вот со дня на день ждем-с... |
Quote: |
Но почему тебя волнует именно распаковка? |
Mowgli wrote: |
Вероятно просто потому, что я сейчас делаю плагин для распаковки. Да и что изменится в плане вышеобсуждённого вопроса для других операций? |
Quote: |
- во-первых, никак нельзя описывать работу этих функций по-отдельности, поскольку они являются частью одного алгоритма. |
Mowgli wrote: |
Т.е. утверждается, что ProcessFile не будет вызываться, если файл был открыт для составления списка файлов. Это неправда и противоречит написанному в том-же документе в разделе о функции ProcessFile. |
Quote: |
Список файлов я составляю уже в функции OpenArchive, |
Mowgli wrote: |
Дальнейшая навигация внутри архива и даже повторные заходы в этот архив осуществляются без участия плагина. |
Mowgli wrote: |
Казалось бы, у TC уже есть имена файлов из архива, мог бы и передать нам, дабы не извлекать их ещё раз. |
Mowgli wrote: |
но учитывая, что деструкторы исключений не вызывают |
Mowgli wrote: |
Полный путь для распаковки содержится в двух аргументах DestName и DestPath. В офф. документации замечательно написано:
Either DestName contains the full path and file name and DestPath is NULL, or DestName contains only the file name and DestPath the file path. ... Как это понимать? Надо проверять по какому варианту сейчас взбрело в голову TC передать этот путь? |
Mowgli wrote: |
А вот какой файл в архиве распаковывать, придётся узнавать самостоятельно. TC это несомненно знает, но молчит. |
Mowgli wrote: |
Расчёт очевидно идёт на то, что обход файлов осуществляется строго в том же порядке, что и при получении списка файлов. |
Quote: |
Весьма странное утверждение. Поскольку кирпич является частью здания нельзя описывать свойства кирпича не описав свойств здания в целом? |
Quote: |
Это, конечно, неточность |
Quote: |
Мне просто любопытно стало - а для каких архивов ты пишешь плагин? Ну и возник ряд других вопросов. Может ли количество файлов в твоём архиве достигать сотен тысяч или миллионов? Если да, то сколько памяти потребуется при вызове функции OpenArchive? Сколько времени ты будешь составлять этот список если архивный файл лежит на сетевом ресурсе? |
Quote: |
Дальнейшая навигация внутри архива и повторные заходы в этот архив могут осуществляться без участия плагина. |
Quote: | ||
|
Quote: |
Если хочется можно и проверять, но проще конкатенировать две строки и двигаться дальше. |
Quote: |
"Узнавать" - это сильное выражение в данном контексте. ТС передает тебе hArcData, который ассоциирован тобой же с текущим файлом. Так что эта фраза звучит примерно как "У меня есть адрес строки. Теперь мне самостоятельно придётся узнать что это за строка". |
Quote: | ||
|
Mowgli wrote: |
Люблю аналогии. Вот ещё одна: как понять назначение колеса, если нет телеги? |
Mowgli wrote: |
В каком случае TC захочет перечитать заново содержимое архива? |
Mowgli wrote: |
Если архив не менялся, то зачем ему это может потребоваться? |
Quote: |
И наконец, какова может быть роль плагина в навигации внутри архива? |
Mowgli wrote: |
Правильно написанные деструкторы исключений вызывать не должны. В противном случае они нарушают спецификацию языка C++. |
Mowgli wrote: |
Если бы DestPath был пустой строкой, то да. А так он NULL. Всё равно проверять надо. |
Mowgli wrote: |
Для начала hArcData - это ещё не текущий файл в архиве. |
Mowgli wrote: |
При этом TC очевидно полагается на то, что список файлов вторично построенный плагином и его, сохранённый ранее, будут в точности совпадать. Если они не будут совпадать, то начнутся большие проблемы. |
Mowgli wrote: |
В каком случае TC захочет перечитать заново содержимое архива? |
Worros wrote: | ||
|
VadiMGP wrote: |
Я тоже люблю отвечать вопросом на вопрос. Но какой в этом смысл в данном случае? |
Quote: |
Не спецификацию, а рекомендацию. |
Quote: |
Например, если класс не содержит конструктора по умолчанию, то нет никаких проблем с исключениями в деструкторе. |
Quote: |
Я никогда не пользовался STL, так что тебе виднее. Я пользуюсь ATL или MFC. Там дополнительных проверок не требуется. |
Quote: |
заново начинает делать перебор всех файлов. И когда твой плагин во время очередного вызова ReadHeader возвращает нужный файл, то последующий вызов ProcessFile будет с параметром PK_EXTRACT. |
Code: |
tOpenArchiveData arch_data = {}; |
Code: |
tOpenArchiveData arch_data = {}; |
Mowgli wrote: |
Да, в самом деле нельзя описать кирпич, не описав предвартельно здание. |
Mowgli wrote: |
Нулевой указатель имеет однозначную интерпретацию - память под объект не выделена. |
Mowgli wrote: |
Да, написано should. Можно и не следовать этому указанию. Примерно, как можно не следовать указанию "не влезай - убъёт" на высоковольтном щитке. |
output generated using printer-friendly topic mod. All times are GMT + 4 Hours