Возьмём этот вопрос на примере юникодных/анси строк хотя он на самом деле шире.
В WinAPI принят такой подход, что все фукции например вида CreateFileXXX (CreateFileA, CreateFileExA, CreateFileW) внутренне вызывают одну функцию CreateFileExW, при необходимости преобразуя в Unicode входные аргументы и добавляя значения по умолчанию при переходе скажем CreateFileW -> CreateFileExW. Ну и все остальные неюникодные функции это делают.
В CRT наоборот анси-версии функций скажем strlen полноценно реализованы а не сведены к юникодным скажем strlen могла бы внутренне вызывать wcslen, но не делает этого. Вместо этого по сути дублируется код для юникодной функции.

Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

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

T>Возьмём этот вопрос на примере юникодных/анси строк хотя он на самом деле шире.
T>В WinAPI принят такой подход, что все фукции например вида CreateFileXXX (CreateFileA, CreateFileExA, CreateFileW) внутренне вызывают одну функцию CreateFileExW, при необходимости преобразуя в Unicode входные аргументы и добавляя значения по умолчанию при переходе скажем CreateFileW -> CreateFileExW. Ну и все остальные неюникодные функции это делают.
T>В CRT наоборот анси-версии функций скажем strlen полноценно реализованы а не сведены к юникодным скажем strlen могла бы внутренне вызывать wcslen, но не делает этого. Вместо этого по сути дублируется код для юникодной функции.
T>Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

ИМХО, для функций работы со строками логичнее "дублировать код", т.к. это именно работа со строками как с разными типами данных. На самом деле там нет никакого дублирования, в каждом случае будет разный код. И форматы строк не ограничены ANSI и UNICODE, может быть еще множество форматов строк (BSTR вроде хранит свой размер по смещению -4, и т.д.).

Для операций с файлами работа со строками — не главное, там логичнее иметь единый код, рассчитанный на какую-то строку, и набор "оберток" для других типов строк.

Ответ известен: функциональный.

Сейчас почитаю, что ты там написал...

T>Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

Здесь имеет смысл.

Но так делать надо только в случае, когда точно известно, что так делать имеет смысл. Например, мы точно уверены в том, что в этом куске кода будет узкое место. Или нам профайлер про это сказал, причём после того, как сказал пользователь. Лучше, когда второе, конечно.

В случае же CreateFileX премя на преобразование не сопоставимо с временем создания файла. Поэтому мы можем тормозить достаточно долго на удобных для открытия файла преобразованиях.

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

T>Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

Для CreateFile — реализовать самую общую верию, и остальные через неё.
Для строк — реализовать С++ template с traitsами для разных кодировок.

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

T>Возьмём этот вопрос на примере юникодных/анси строк хотя он на самом деле шире.
T>В WinAPI принят такой подход, что все фукции например вида CreateFileXXX (CreateFileA, CreateFileExA, CreateFileW) внутренне вызывают одну функцию CreateFileExW, при необходимости преобразуя в Unicode входные аргументы и добавляя значения по умолчанию при переходе скажем CreateFileW -> CreateFileExW. Ну и все остальные неюникодные функции это делают.
T>В CRT наоборот анси-версии функций скажем strlen полноценно реализованы а не сведены к юникодным скажем strlen могла бы внутренне вызывать wcslen, но не делает этого. Вместо этого по сути дублируется код для юникодной функции.
strlen — вообще зло. Все строки обязаны быть оборудованы длиной с самого начала. В нормальных платформах так и сделано.

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

S>strlen — вообще зло. Все строки обязаны быть оборудованы длиной с самого начала. В нормальных платформах так и сделано.

В "нормальных платформах" скрыт способ указания длины строки, т.к. в противном случае мы получали кучу несовместимых представлений, от паскалевской строки, где под длину отводился 1 байт, до BSTR. Однако, под нормальную платформу и CString из MFC/ATL попадает, и std::string.

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

Я думаю тут всё просто — когда создавался C, были только ansi строки, их заимплементировали. Потом появился юникод. Его тоже заимплементировали, отдельно. А в MS, когда разрабатывали NT, решили сразу сэкономить и сделали всё на основе юникода. И, я думаю, обоснованно, т.к. сейчас уже трудно найти неюникодные программы.

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

T>>В CRT наоборот анси-версии функций скажем strlen полноценно реализованы а не сведены к юникодным скажем strlen могла бы внутренне вызывать wcslen, но не делает этого. Вместо этого по сути дублируется код для юникодной функции.
S>strlen — вообще зло. Все строки обязаны быть оборудованы длиной с самого начала. В нормальных платформах так и сделано.

Какой должна быть эта длина? 1 байт? 2? 4? 8?

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

T>Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

wcslen по определению предназначена для юникодных нуль-терминированных строк. strlen — для ASCIIZ. Тогда как CreateFileExW — часть подсистемы ввода-вывода, которая может оперировать вообще сугубо своей собственной персональной кодировкой имён. Иными словами — нужно отдавать себе отчёт, где, что и ради чего сделано. И тогда вопроса об "общих соображениях" вообще не возникнет, поскольку им тут нет места.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Какой должна быть эта длина? 1 байт? 2? 4? 8?
Это деталь реализации. Я говорю о поведении. Совершенно нормальным было бы использовать плавающий енкодинг типа UTF-8, который бы позволял произвольные длины строк.

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

T>Считаете ли вы из самых общих соображений разумным сдублировать код но сэкономить время на преобразования (время кстати очень существенное по сравнению со временем выполнения той же strlen)?

Что касается конкретно строк, то я считаю, что вся эта байда в С вызвана отсутствием стратегии совместимости и долгим и упорным игнорированием юникода.

В современных языках и рантаймах используется исключительно юникод.

Что касается выбора, то странно об этом слышать от С++-ника. Уж кто-кто, а С++ обладает отличным средством решения проблем дублирования кода — шаблонами. Реализуй функции работы со строками в виде шаблонов и получи эффективную и гибкую реализацию. Собственно, как я понимаю, так и сделано в std::string.

Так что имеет смысл снова вернуться к вопросу стратегий и задаться вопросом — "Какого черта в С++ используется такое количество разнообразных реализаций API работы со строками?".

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

ГВ>>Какой должна быть эта длина? 1 байт? 2? 4? 8?
S>Это деталь реализации. Я говорю о поведении. Совершенно нормальным было бы использовать плавающий енкодинг типа UTF-8, который бы позволял произвольные длины строк.

Спорно насчёт "совершенной нормальности". Прежде всего из-за не очень оправданных потерь в производительности. Каждая операция оценки длины строки в этом случае потянет за собой вычисления, перекодировки, сдвиги-передвиги и т.п. ИМХО — не слишком симпатично для "вообще". Но такой подход оправдан там, где имеет значение размер самих данных, например — в форматах передачи по сети.

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

VD>Так что имеет смысл снова вернуться к вопросу стратегий и задаться вопросом — "Какого черта в С++ используется такое количество разнообразных реализаций API работы со строками?".

Задачи разные. Разные и методы их решений. И это есть хорошо — пусть зацветают тысячи цветов. С другой стороны, при необходимости можно с лёгкостью скрестить ужа с ежом, например, вот такой библиотекой свободных функций (они как раз почему-то порицаются "современными платформами"):

template<typename StrType> int str_get_length(const StrType &);
template<typename StrType>
typename CharTypeDetector<StrType>::CharType str_get_char(const StrType &, int index);
// и т.п.

И склеивай что хошь с чем заблагорассудится.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Спорно насчёт "совершенной нормальности". Прежде всего из-за не очень оправданных потерь в производительности. Каждая операция оценки длины строки в этом случае потянет за собой вычисления, перекодировки, сдвиги-передвиги и т.п.
Это рассуждения на уровне "ой, БПФ — это как-то сложно, давайте лучше обычное ДПФ применим".

Давайте сделаем оценку сложности O(F(N)) для такого представления. Мне почему-то кажется, что там будет O(log32(N)) или около того, т.е. во всех практических случаях — O(1).
Насчет сети — да.

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

S>Давайте сделаем оценку сложности O(F(N)) для такого представления. Мне почему-то кажется, что там будет O(log32(N)) или около того, т.е. во всех практических случаях — O(1).

Во-первых, что ты подразумеваешь под N? Что за log32?

Во-вторых, тут не важна оценка сложности самих вычислений. Важно то, есть эти самые дополнительные вычисления или нет.