LINUX.ORG.RU

В поисках чего-то легковесного для работы с ФС

 , ,


0

1

Писал небольшой проект (2D игра, C++/SFML), как говорится, «для души». Но появились кое-какие перспективы на дальнейшее развитие и монетизацию, решил портировать на другие платформы: сборка под мак прошла гладко, заработало все сразу. А вот с виндой вечно какие-то проблемы... То собираться не желает (привет соблюдению стандартов в мелкомягком компиляторе), то еще какая-нибудь хрень. Потанцевав с бубном, обнаружил, что под виндой как-то некорректно воспринимаются пути к файлам. Посоветуйте какую-нибудь легковесную либу для работы с ФС (стандартное вроде только в C++17 завезли, и я не особо хочу на него переходить), чтобы не проектировать велосипед.

★★★★

Ответ на: Offtop. от commagray

ООП альтернатива. Плюс реализовано куча вещей, которые с SDL бы все равно пришлось писать самому ;) Экономия времени.

Meyer ★★★★ ()

Чтобы писать для винды, желательно найти спонсора, инвестора или мецената...

anonymous ()

под виндой как-то некорректно воспринимаются пути к файлам

Вот первый раз такое слышу/вижу. Сколько работал всегда было нормально (boost, stdio, std::file*). Начиная с XP даже можно в юникс стиле писать (/ вместо \).

Возможно вы просто чтото намутили с опциями компиляции, дело в том что если под виндой собирать в UNICODE то все системные вызовы будет ожидать на входе UTF16 строки (в том числе и всякие open/fopen и тд). Но при этом если вы в исходнике укажите fopen(«abc.txt», «r») то файл не откроется, так как строка с именем файла будет ANSI (7 байт) вместо UTF16 (14 байт). Тут либо константы менять (через макрос T()) либо просто пересобрать весь проект не под юникод а под легаси вызовы (но там могут быть свои приколы) ...

zaz ★★★★ ()
Ответ на: комментарий от Meyer

Там все еще более запущено, на самом все библиотечные функции это дефайны, и тотже fopen разворачивается либо в fopen_a который на входе принимает сhar* либо в fopen_w который на вход принимает wchar*. Точно также и по системным вызовам, есть вызов CreateFileA - для char* а есть CreateFileW для wchar*.

Когда вы у себя в коде пишете fopen то он разворачивается либо в fopen_a либо в fopen_w в зависимости от дефайна UNICODE.

Вобщем там костылей вагон и тележка. Но для начала попробуйте просто собратся под не юникод (в VS вроде 3 опции под это дело есть, «Non Unicode», «Unicode», «Multibyte charset» )

zaz ★★★★ ()

Тебе прямо принципиально ООП? Ну вон из Quake код берни в классы. Как правило, ничем хорошим оборачивание или даже переписывание с ООП в уме таких базовых вещей не кончается. Ну будет класс CFile, который закроет дескриптор по деструктору, если файл с диска, да в общем-то всё.

Если прямо невтерпеж хочется нормально на крестах, то смотри в Дум3. Я считаю вполне неплохой GPL-ный пример без излишков.

a1batross ★★★★★ ()
Последнее исправление: a1batross (всего исправлений: 1)

что под виндой как-то некорректно воспринимаются пути к файлам

А можно пример?

Deleted ()
Ответ на: комментарий от Deleted

Например - кириллические символы в пути к файлу. Вместо них какая-то абракадабра. Под никсами такой фигни нет.

Meyer ★★★★ ()
Ответ на: комментарий от Meyer

В смысле путь берётся из конфига? Или ты имеешь ввиду проблемы с путём к конфигу? Если проблемы с путём к конфигу, то откуда ты этот путь берёшь? В общем без кода непонятно где именно у тебя проблемы возникают.

Deleted ()
Ответ на: комментарий от Deleted

А, не суть важно. Суть проблемы - любое присутствие символов не латинского алфавита все ломает. В винде не научились в UTF-8 по-умолчанию?

Meyer ★★★★ ()
Ответ на: комментарий от a1batross

Если прямо невтерпеж хочется нормально на крестах, то смотри в Дум3.
на крестах
Дум3

Отличный пример того, как не нужно писать на крестах. Я, конечно понимаю, наследие кваки и тяжелые годы заставили Кармака так все сделать, но все же.

Meyer ★★★★ ()
Ответ на: комментарий от Meyer

А, не суть важно.

Важно!

Суть проблемы - любое присутствие символов не латинского алфавита все ломает.

УМВР

В винде не научились в UTF-8 по-умолчанию?

А что, где-то научились?

Deleted ()

C++17 завезли, и я не особо хочу на него переходить

Почему? Неужели тебе так охота городить костыли?

В винде не научились в UTF-8 по-умолчанию?

Нет, а зачем? UTF-16 работает как надо.

Unicode4all ★★★★★ ()
Последнее исправление: Unicode4all (всего исправлений: 1)
Ответ на: комментарий от Meyer

Наоборот. Хороший сишник на крестах напишет лучше, чем тот кто всегда писал на крестах. Он же и знает когда реально надо перекатиться в ООП, а когда можно остаться в процедурщине.

a1batross ★★★★★ ()
Ответ на: комментарий от Meyer

А вообще у тебя проблема только с виндой. Возьми винду и отдебажь то, что есть у тебя сейчас. Это какой-то слишком не повод искать либы.

a1batross ★★★★★ ()

Вангую, что значения из чего-то вроде переменных окружения не были правильно преобразованы в узкий набор символов (непредставимы из-за локали, например), но при этом используются. Самый простой способ это на входе из системы преобразовывать в UTF-8, а при использовании в UTF-16. UTF-8 нужен так как не факт, что системная локаль позволит хранить весь Unicode.

xaizek ★★★★★ ()
Ответ на: комментарий от SR_team

Steamworks нужен. А он доступен, вроде как, только для мелкомягкого говна.

Meyer ★★★★ ()

Советую boost::filesystem или лучше std::filesystem. Под виндой всегда надо помнить про UTF-16 (точнее UCS-2) в путях. Хорошен решение - всё в строках держать в utf8, использовать литералы u8"", использовать std filesystem и функцию u8path для конструирования пути. Прелесть std filesystem в абстрагировании от кодировки, главное на входе и на выходе не испортить её. P.S. fopen забань, используй fstream и метод native у path: начиная с c++17, fstream принимает как string, так и wstring.

quiet_readonly ★★★★ ()
Последнее исправление: quiet_readonly (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.