так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?
Здравствуйте, _hum_, Вы писали:
__>так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?
неправильно вы рассуждаете
STL (а именно это и стандартизуется) пишут под платформу. у платформы есть документация, которая говорит, в какой кодировке должны путь файловые пути. STL удовлетворяет эти требования. не вижу принципиальных проблем, да и библиотеки, которые сразу на много платформ, уже показали, что в принципе это реализуемо. (см. буст, qt)
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, _hum_, Вы писали:
__>>так а где там видно, что так можно (приницпиально)? по идее, для этого у системного апи должна быть функция, которая бы возвращала формат, в котором ос предполагает обращение к файлу. тогда бы c++ мог бы автоматом конвертить из unicod-а в нужный формат, без участия программиста. вот я и интересуюсь, такое вообще возможно? есть ли там какие стандарты на ос, требующие поддержку соответствующей функции?
U>неправильно вы рассуждаете U>STL (а именно это и стандартизуется) пишут под платформу. у платформы есть документация, которая говорит, в какой кодировке должны путь файловые пути.
ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)
Здравствуйте, _hum_, Вы писали:
__>ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)
даже если бы и были такие правила, то опять же на уровне стандарта наверняка можно было бы все разрулить. стандартизируется абстракция, далее уже конкретная реализация использует системное API
на текущий момент проблем стандартного метода stream::open(char*) в том, что не зафиксировано, в какой же кодировке передается строка. каждая реализация STL по-своему интерпретирует переданный аргумент
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, _hum_, Вы писали:
__>>ну да, при условии, что у всех платформ правила обращения к файлу по имени одинаковые (например, нет такого, что на какой-то платформе кодировкак зависит от того, в какой директории лежит файл)
U>даже если бы и были такие правила, то опять же на уровне стандарта наверняка можно было бы все разрулить. стандартизируется абстракция, далее уже конкретная реализация использует системное API
в этом месте как раз может быть прокол — нужная абстракция (открытие файла по unicode) может не покрывать все случаи (например, если платформа вообще хранит файлы в разных форматах наименования так, как они были созданы), а потому ее придется расширять и делать самый общий вариант, как счас — открываю в том формате, что передали.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, _hum_, Вы писали:
__>>придется расширять и делать самый общий вариант, как счас — открываю в том формате, что передали.
U>да, придется расширять
ну а значит, нельзя будет сужать существующий на данный момент вариант ( open(char* unknown_format_filename) ), о чем я и вел речь (что такое гипотетически возможно)
