Re[10]: проблема с std::ifstream::open
От: _hum_ Беларусь  
Дата: 04.10.16 12:22
Оценка:
Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:


__>>попутно вопрос: это принципиально невозможно, или просто недоработка языка?


U>скорее, недоработка

U>немного инфы здесь: http://stackoverflow.com/questions/23393870/read-write-file-with-unicode-file-name-with-plain-c-boost

так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?
Re[11]: проблема с std::ifstream::open
От: uzhas Ниоткуда  
Дата: 04.10.16 12:40
Оценка:
Здравствуйте, _hum_, Вы писали:

__>так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?


неправильно вы рассуждаете
STL (а именно это и стандартизуется) пишут под платформу. у платформы есть документация, которая говорит, в какой кодировке должны путь файловые пути. STL удовлетворяет эти требования. не вижу принципиальных проблем, да и библиотеки, которые сразу на много платформ, уже показали, что в принципе это реализуемо. (см. буст, qt)
Re[12]: проблема с std::ifstream::open
От: _hum_ Беларусь  
Дата: 04.10.16 13:03
Оценка:
Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:


__>>так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?


U>неправильно вы рассуждаете

U>STL (а именно это и стандартизуется) пишут под платформу. у платформы есть документация, которая говорит, в какой кодировке должны путь файловые пути.

ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)
Re[13]: проблема с std::ifstream::open
От: uzhas Ниоткуда  
Дата: 04.10.16 14:19
Оценка:
Здравствуйте, _hum_, Вы писали:

__>ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)


даже если бы и были такие правила, то опять же на уровне стандарта наверняка можно было бы все разрулить. стандартизируется абстракция, далее уже конкретная реализация использует системное API
на текущий момент проблем стандартного метода stream::open(char*) в том, что не зафиксировано, в какой же кодировке передается строка. каждая реализация STL по-своему интерпретирует переданный аргумент
Re[14]: проблема с std::ifstream::open
От: _hum_ Беларусь  
Дата: 04.10.16 14:56
Оценка:
Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:


__>>ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)


U>даже если бы и были такие правила, то опять же на уровне стандарта наверняка можно было бы все разрулить. стандартизируется абстракция, далее уже конкретная реализация использует системное API


в этом месте как раз может быть прокол — нужная абстракция (открытие файла по unicode) может не покрывать все случаи (например, если платформа вообще хранит файлы в разных форматах наименования так, как они были созданы), а потому ее придется расширять и делать самый общий вариант, как счас — открываю в том формате, что передали.
Re[15]: проблема с std::ifstream::open
От: uzhas Ниоткуда  
Дата: 04.10.16 14:59
Оценка:
Здравствуйте, _hum_, Вы писали:

__>придется расширять и делать самый общий вариант, как счас — открываю в том формате, что передали.


да, придется расширять
Re[16]: проблема с std::ifstream::open
От: _hum_ Беларусь  
Дата: 04.10.16 15:11
Оценка:
Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:


__>>придется расширять и делать самый общий вариант, как счас — открываю в том формате, что передали.


U>да, придется расширять


ну а значит, нельзя будет сужать существующий на данный момент вариант ( open(char* unknown_format_filename) ), о чем я и вел речь (что такое гипотетически возможно)
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.