chiaroscuro
>Что значит "красиво"? Зачем нужна "красивая" реализация?
>EDIT: каковы требования? почему не устраивает то, что есть сейчас?
Не так выразился )
Красиво - значит читабельно и интуитивно понятно )
Просто мне кажется что если другой программист увидит такой код:
image.load("Data/images/", "image1.png", "D:/data.zip");
То он не сразу поймет откуда читается картинка, хотя может я слишком загоняюсь.
VFS
> image.load("Data/images/", "image1.png", "D:/data.zip");
Мне тоже такая запись не нравится. Вместо передачи 2 параметров в функцию нужно передать 3. А внутри все равно придется склеивать 2 строки.
image.load("Data/images/image1.png", "D:/data.zip");
Так намного понятнее.
Гораздо лучше будет выглядеть image.load("image1.png");
nes
> Красиво - значит читабельно и интуитивно понятно )
Ну хорошо. Ясно, наверное, что вещи, "интуитивно понятные" одному человеку, могут быть непонятны другому. Следует ли из-за этого гнаться за такой понятностью?
> Просто мне кажется что если другой программист увидит такой код:
>
> image.load("Data/images/", "image1.png", "D:/data.zip");
>
> То он не сразу поймет откуда читается картинка, хотя может я слишком загоняюсь.
Если хочешь, чтобы человек сразу понял, откуда читается картинка, можешь сделать так:
- записать правила определения пути к файлу в документации к image.load (чтобы можно было без особого труда определить по ним, откуда должна читаться картинка)
- предоставить средства дебага (тут может быть хотя бы fprintf в stderr сообщения вида "картинка X считывается из Y", -- зависит от ситуации)
(это все нужно будет тогда, когда у читающего возникнет насущная необходимость узнать, откуда именно читается картинка)
nes
> В чем профит хранить все ресурсы в едином файле?
Там про memory mapped скорее.
nes
Опять таки:
g_pMyFileSystem->AddPack( "packs/maps.pak", "maps/" ); ... MyFile::Ptr pFile = g_pMyFileSystem->Open( "maps/level1/loading_screen.png" );
Вот таким образом мъ смонтировали пак по пути "maps/" - все пути "maps/*" сначала посмотрят в пак, потом уже во внешний FS (если разрешено конечно) в поисках файла. Таким же образом можно транслировать пути из одного фолдера в другой, совсем прозрачно для кода, которъй читает файлъ.
image.load("Data/images/", "image1.png", "D:/data.zip");Какой кошмар. Во-первых хардкодить полные пути это зло. А во-вторых если надо 100 картинок, то в каждой название зипа прописывать что ли? А если потом имя файла поменяется?
+1 к 21-му посту
Z
+1, все правильно.
Все понятно всем спасибо, сделал все намного проще - отказался от архива, т.к. все файлы у меня бинарные не вижу смысла держать их в архиве.
А вот про "memory mapped" хотелось бы узнать по-подробнее, что это такое?
nes
> А вот про "memory mapped" хотелось бы узнать по-подробнее, что это такое?
Если не вдаваться в детали:
Содержимое файла "отображается" в виртуальную память процесса. Для выполняющейся программы выглядит это так: получаем некий указатель (на массив байтов), по которому можем читать/писать. Операционная система отслеживает такие операции, и подгружает части файла с диска.
nes
> memory mapped
Это отображение файла в адресное пространство. Доступ к файлу осуществляется как к массиву байтов через указатель.
+Более быстрый доступ для чтения/записи файла, чем стандартные функции о работе с файлом.
-Нельзя дописывать файл (т.е. увеличивать размер).
chiaroscuro
asvp
А ну это фигня, мне такое не надо, так что отдельные файлы - мое решение )
Тема в архиве.