Просматриваю содержимое boost'а. Типа как “one of the most highly regarded and expertly designed C++ library projects in the world”.
Возникают вопросы по поводу организации библиотек и размещения исходных файлов (примеры ниже). Раз уж это "одна из наиболее хорошо спроектированных библиотек", значит я чего-то не понимаю. Может кто объяснит?
Далее примеры из нескольких библиотек буста.
boost.serialization.extended_type_info здесь
Какое отношение extended_type_info имеет к сериализации? Кроме того, что она использует extended_type_info. По-моему, это совсем отдельная фича, которую я бы расположил в отдельном месте. Они же сами в мотивации приводят ряд проблем с std::type_info. Эти проблемы касаются не только boost.serialization. А если завтра какой-то ещё библиотеке понадобится extended_type_info они свой велосипед будут делать?
Или здесь см struct tri_state с соответствующим комментарием.
Блин, у них же специально для этого есть Boost.Tribool здесь или boost.optionalздесь. А если кому-то из разработчиков boost понадобиться bind, он тоже сам будет реализовывать в своём hpp'шнике?
boost.serialization.dataflow здесь
Опять же какое это имеет отношение к serialization? Кроме как что она использует Dataflow Iterators. Вещь очень полезная, удобная и расширяемая. Сама по себе без всякого serialization. Пока не залезешь в дебри serialization о ней даже не узнаешь!
Или boost.spirit.file_iterator здесь
Всё аналогично. Вещь полезная сама по себе и не имеющая отношения к spirit. И опять же пока в spirit не будешь разбираться о ней не узнаешь.
Ещё есть замечательные функции to_utf8/from_utf8. Удивляетесь, что видите их первый раз? Не удивительно, если учесть, что их надо подключать как
#include <boost/program_options/detail/convert.hpp>
Я никогда не пользовался boost.program_options. Ну так поглядел, для чего она нужна в общих чертах. Но в detail не заглядывал. Однако потребность в такой удобной функции to_utf8 возникала неоднократно.
Примеров такого рода, я думаю, можно много привести. Т.е. что имеет место: в основном (по-моему) неправильное размещение большого количества различных утилит и тулзов, там где они не доступны и неизвестны другим. + иногда даже дублирование некоторых вещей.
Как это объяснить?
Первый вариант. "Я делаю serialization, мне на всех по*рать, я самый крутой, не хочу знать чо там у вас ещё есть, потомучто это всё убогое, и все свои утилиты я ношу с собой, потомучто они самые крутые и все должны знать, что они относятся именно к serialization, который сделал Я!"
Второй вариант. "Я делаю serialization. Я очень занят и мне некогда смотреть, что там у вас ещё есть. Я не видел, что уже есть Boost.Tribool. Я сделал сам похожее. А свои тулзы класть в общее место... зачем? их только я использую, я их для себя делал..."
Третий вариант. Если попробовать как-то их оправдать — может общий код выносится в общие места только по мере необходимости, когда его хотят юзать хотя бы две библиотеки.
Или может общего начала не хватает. Не хватает человека, который мог бы открыть любую библиотеку. поглядеть и сказать "@#$ли ты, Robert Ramey, это сюда положил. Анука переделывай!".
Как-то сомнительно это. Эти инструменты хотели бы юзать много людей отдельно. Почему бы их сразу не класть нормально?
А первые 2 варианта лечатся воспитательной работой и просмотрами кода.
В общем, что я хочу сказать. Или я чего-то не понимаю или это никакая не “one of the most highly regarded and expertly designed C++ library projects in the world”.
Здравствуйте, remark, Вы писали:
R>Просматриваю содержимое boost'а. Типа как “one of the most highly regarded and expertly designed C++ library projects in the world”. R>Возникают вопросы по поводу организации библиотек и размещения исходных файлов (примеры ниже). Раз уж это "одна из наиболее хорошо спроектированных библиотек", значит я чего-то не понимаю. Может кто объяснит?
Как мне объясняли (Joel de Guzman по-моему) для того, чтобы какая-та библиотека или фича попала в буст, необходимо пройти review или в случае малого размера fast-track review. Однако этот процесс достаточно не удобен для разработчика, у которого уже есть accepted библиотека в бусте: нужно написать Review Wizard'у, поставить запрос на ревью в очередь, найти того, кто будет согласен быть Review Manager. Это всё очень долго.
Поэтому всё делают по-другому. Как только какая-то библиотека стала "accepted", и удовлетворяет требованиям Review Managerа, автор библиотеки может делать с ней всё, что хочет. И он этим по праву пользуется. Если ему необходима какая-то функциональность, которой нет в бусте на данный момент, он просто пишет ее и добавляет ее где-то у себя под капотом библиотеки. Причем документировать внутренности вообще не обязан, поэтому в бусте много полезных вещей, о которых почти никто не знает.
R>Далее примеры из нескольких библиотек буста.
[snipped]
R>Примеров такого рода, я думаю, можно много привести. Т.е. что имеет место: в основном (по-моему) неправильное размещение большого количества различных утилит и тулзов, там где они не доступны и неизвестны другим. + иногда даже дублирование некоторых вещей.
Дублирование порой происходит из правильных соображений например BOOST_FOREACH совершенно не нужна зависимость от boost::mpl, поэтому там есть свой type2type.
Или признак конца списка типов может быть boost::tuples::null_type, boost::mpl::na, boost::fusion::void_. Лично мне это доставило много проблем.
R>Как это объяснить? R>Первый вариант. "Я делаю serialization, мне на всех по*рать, я самый крутой, не хочу знать чо там у вас ещё есть, потомучто это всё убогое, и все свои утилиты я ношу с собой, потомучто они самые крутые и все должны знать, что они относятся именно к serialization, который сделал Я!"
См. объяснение выше.
R>Второй вариант. "Я делаю serialization. Я очень занят и мне некогда смотреть, что там у вас ещё есть. Я не видел, что уже есть Boost.Tribool. Я сделал сам похожее. А свои тулзы класть в общее место... зачем? их только я использую, я их для себя делал..."
Boost.TriBool появилось позже, эта функциональности потребовалось кому-то еще, ему было не лень организовать review, написатаь документацию, тесты (Doug Gregor). Весьма вероятно, что boost.serialization через некоторое время перейдет на использование boost.tribool, а не своего (уже велосипеда), но пока и у них есть задачи по важнее.
R>Третий вариант. Если попробовать как-то их оправдать — может общий код выносится в общие места только по мере необходимости, когда его хотят юзать хотя бы две библиотеки.
См. объяснение выше.
R>Или может общего начала не хватает. Не хватает человека, который мог бы открыть любую библиотеку. поглядеть и сказать "@#$ли ты, Robert Ramey, это сюда положил. Анука переделывай!".
Это open-source, они на этом не зарабатывают, это хобби, и их возможно устраивает как все расположено, если тебя нет — "подключайся", тебе обязательно скажут спасибо.
Но нет никто не будет делать, будут ждать когда в бусте станет как мне надо.
R>Как-то сомнительно это. Эти инструменты хотели бы юзать много людей отдельно. Почему бы их сразу не класть нормально? R>А первые 2 варианта лечатся воспитательной работой и просмотрами кода.
Не лечится. Зато можешь попросить ревью для каждой из вышеперечисленных "маленьких" библиотек тут.
R>В общем, что я хочу сказать. Или я чего-то не понимаю или это никакая не “one of the most highly regarded and expertly designed C++ library projects in the world”.
Я бы сказал “one of the most highly regarded and expertly designed open-source C++ library projects in the world”.
Сразу всё претензии исчезают.
Hello, remark!
You wrote on Thu, 16 Mar 2006 02:04:48 GMT:
r> Просматриваю содержимое boost'а. Типа как “one of the most highly r> regarded and expertly designed C++ library projects in the world”. r> Возникают вопросы по поводу организации библиотек и размещения исходных r> файлов (примеры ниже). Раз уж это "одна из наиболее хорошо r> спроектированных библиотек", значит я чего-то не понимаю. Может кто r> объяснит?
Павел достаточно точно все описал. Если бы ты следил за тем как развивается буст то вопросов бы просто не было . Что-то появилось позже, что-то просто одновременно. Разрабатывали два хороших парня библиотеки и нужно им было с utf8 поработать. Вот каждый из них сделал себе по штучке. Когда оба прошли review поняли что у них дубляж. Побубнели друг с другом, поисправляли баги и остались довольны. И таких примеров там очень много. Что-то выделять начинают только тогда когда это кому-то нужно в отдельном виде и кто-то может это выделить, написать документацию, пройти review и еще куча всего. Хотя маленькие либы проходят review влет, все остальное делается не очень быстро. Ну и один из главный аргументов — Open Source Ненравиться — присоединяйся и исправляй
R>Ещё есть замечательные функции to_utf8/from_utf8. Удивляетесь, что видите их первый раз? R>Не удивительно, если учесть, что их надо подключать как R>#include <boost/program_options/detail/convert.hpp> R>Я никогда не пользовался boost.program_options. Ну так поглядел, для чего она нужна в общих чертах. R>Но в detail не заглядывал. Однако потребность в такой удобной функции to_utf8 возникала неоднократно.
The 'to_utf8' function is in the 'detail' namespace for a simple reason. Any top-level library needs extra work:
Documentation
Tests
Review
Stuff in the 'detail' namespace does not need anything. And review is way too long process. The best that's possible is to define this function in <boost/detail/whatever.hpp> header, not in <boost/program_options/detail/whatever.hpp>, but still, that will be part of undocumented interface, use at your own risk. And making it part of the documented interface requires the above work.
Note that this locale and unicode stuff is not universally available, so the work might be significant. And as soon as 'to_utf8' is added as public interface, somebody will come along as ask for 'to_koi8r' function.
BTW, you could have asked this question on the Boost mailing list, where it's more likely to change anything.
R>Ещё есть замечательные функции to_utf8/from_utf8. Удивляетесь, что видите их первый раз? Не удивительно, если учесть, что их надо подключать как R>#include <boost/program_options/detail/convert.hpp> R>Я никогда не пользовался boost.program_options. Ну так поглядел, для чего она нужна в общих чертах. Но в detail не заглядывал. Однако потребность в такой удобной функции to_utf8 возникала неоднократно.
Я попробовал эти функции и понял что они не замечательные. Если wstring хранит строку в UTF-16, а в Windows это именно так, то они должны понимать surrogate pairs. Не понимают .
Здравствуйте, saproj, Вы писали:
R>>Ещё есть замечательные функции to_utf8/from_utf8. Удивляетесь, что видите их первый раз? Не удивительно, если учесть, что их надо подключать как R>>#include <boost/program_options/detail/convert.hpp> R>>Я никогда не пользовался boost.program_options. Ну так поглядел, для чего она нужна в общих чертах. Но в detail не заглядывал. Однако потребность в такой удобной функции to_utf8 возникала неоднократно.
S>Я попробовал эти функции и понял что они не замечательные. Если wstring хранит строку в UTF-16, а в Windows это именно так,
Это вроде называется UCS-2. UTF-16 это с переменным количеством байт на символ, а в Windows на символ всегда 2 байта.
S>то они должны понимать surrogate pairs. Не понимают .
Здравствуйте, Pavel Chikulaev, Вы писали:
PC>Как мне объясняли (Joel de Guzman по-моему) для того, чтобы какая-та библиотека или фича попала в буст, необходимо пройти review или в случае малого размера fast-track review. Однако этот процесс достаточно не удобен для разработчика, у которого уже есть accepted библиотека в бусте: нужно написать Review Wizard'у, поставить запрос на ревью в очередь, найти того, кто будет согласен быть Review Manager. Это всё очень долго. PC>Поэтому всё делают по-другому. Как только какая-то библиотека стала "accepted", и удовлетворяет требованиям Review Managerа, автор библиотеки может делать с ней всё, что хочет. И он этим по праву пользуется. Если ему необходима какая-то функциональность, которой нет в бусте на данный момент, он просто пишет ее и добавляет ее где-то у себя под капотом библиотеки. Причем документировать внутренности вообще не обязан, поэтому в бусте много полезных вещей, о которых почти никто не знает.
Понятно — "хотели как лучше, а получилось как всегда"
Мне кажется, что поскольку это не большая корпорация с жесткой технологией, а как раз опен-сорц, типа как там все стараются на общее и на своё благо. Установили технологию работы, увидели, что она работает не так хорошо и что даёт сбои, можно же что-то поменять. А то напоминают менеджеров крупной организации.
R>>Примеров такого рода, я думаю, можно много привести. Т.е. что имеет место: в основном (по-моему) неправильное размещение большого количества различных утилит и тулзов, там где они не доступны и неизвестны другим. + иногда даже дублирование некоторых вещей. PC>Дублирование порой происходит из правильных соображений например BOOST_FOREACH совершенно не нужна зависимость от boost::mpl, поэтому там есть свой type2type.
Согласен, что делать такую большую библиотеку как большой монолит плохо. Ну опять же, если есть два модуля, один из которых неестественно зависит от другого, их можно разбить на 3 модуля — один базовый и два зависят от него.
PC>Или признак конца списка типов может быть boost::tuples::null_type, boost::mpl::na, boost::fusion::void_. Лично мне это доставило много проблем.
Вот-вот.
R>>Второй вариант. "Я делаю serialization. Я очень занят и мне некогда смотреть, что там у вас ещё есть. Я не видел, что уже есть Boost.Tribool. Я сделал сам похожее. А свои тулзы класть в общее место... зачем? их только я использую, я их для себя делал..." PC>Boost.TriBool появилось позже, эта функциональности потребовалось кому-то еще, ему было не лень организовать review, написатаь документацию, тесты (Doug Gregor). Весьма вероятно, что boost.serialization через некоторое время перейдет на использование boost.tribool, а не своего (уже велосипеда), но пока и у них есть задачи по важнее.
Такое объяснение мне приходило на ум. Неужели у них такой мегатяжёлый процесс, что провести небольшой рефакторинг это конец света?
R>>Или может общего начала не хватает. Не хватает человека, который мог бы открыть любую библиотеку. поглядеть и сказать "@#$ли ты, Robert Ramey, это сюда положил. Анука переделывай!". PC>Это open-source, они на этом не зарабатывают, это хобби, и их возможно устраивает как все расположено, если тебя нет — "подключайся", тебе обязательно скажут спасибо. PC>Но нет никто не будет делать, будут ждать когда в бусте станет как мне надо.
Ессно
Причины есть — во-первых всё на английском. Во вторых непонятно, что? чего? как? где? с кем? когда? почему? зачем? и т.д. В тетьих на это надо больше времени. В четвёртых ессно лень
R>>В общем, что я хочу сказать. Или я чего-то не понимаю или это никакая не “one of the most highly regarded and expertly designed C++ library projects in the world”. PC>Я бы сказал “one of the most highly regarded and expertly designed open-source C++ library projects in the world”. PC>Сразу всё претензии исчезают.
Хоть и open-source, но мне кажется, что там должен быть костяк людей, которые плотно общаются, которые видят ситуацию, которые могут что-то изменить. Ну в общем, котрые могли бы занимать более активную позицию.
Здравствуйте, Dark Angel, Вы писали:
DA>Hello, remark! DA>You wrote on Thu, 16 Mar 2006 02:04:48 GMT:
r>> Просматриваю содержимое boost'а. Типа как “one of the most highly r>> regarded and expertly designed C++ library projects in the world”. r>> Возникают вопросы по поводу организации библиотек и размещения исходных r>> файлов (примеры ниже). Раз уж это "одна из наиболее хорошо r>> спроектированных библиотек", значит я чего-то не понимаю. Может кто r>> объяснит?
DA> Павел достаточно точно все описал. Если бы ты следил за тем как развивается буст то вопросов бы просто не было . Что-то появилось позже, что-то просто одновременно.
Я думаю, что одновременно появлялось мало чего. Причина не в этом.
Позже. Возможно.
DA> Разрабатывали два хороших парня библиотеки и нужно им было с utf8 поработать. Вот каждый из них сделал себе по штучке. Когда оба прошли review поняли что у них дубляж. Побубнели друг с другом, поисправляли баги и остались довольны. И таких примеров там очень много.
Я думаю, мало.
DA> Что-то выделять начинают только тогда когда это кому-то нужно в отдельном виде и кто-то может это выделить, написать документацию, пройти review и еще куча всего. Хотя маленькие либы проходят review влет, все остальное делается не очень быстро.
Большинство вещей, которые я упоминал именно маленькие либы. Это не целый serealization или spirit.
S>>Я попробовал эти функции и понял что они не замечательные. Если wstring хранит строку в UTF-16, а в Windows это именно так,
R>Это вроде называется UCS-2. UTF-16 это с переменным количеством байт на символ, а в Windows на символ всегда 2 байта.
Советую прочитать What is the difference between UCS-2 and UTF-16?. Если после этого вопросы не отпадут, то спрашивай.
S>>то они должны понимать surrogate pairs. Не понимают .
R>А что такое surrogate pairs?
Вот пример: L"\xd800\xdc00".
А за подробностями в гугл.
Здравствуйте, saproj, Вы писали:
S>>>Я попробовал эти функции и понял что они не замечательные. Если wstring хранит строку в UTF-16, а в Windows это именно так,
R>>Это вроде называется UCS-2. UTF-16 это с переменным количеством байт на символ, а в Windows на символ всегда 2 байта.
S>Советую прочитать What is the difference between UCS-2 and UTF-16?. Если после этого вопросы не отпадут, то спрашивай.
... мда, там говориться, что UCS-2 вообще устаревшее понятие.
Там например идёт речь о символах в диапазоне 100000..10FFFD — это не поместиться в wchar_t. И всё таки может ли в UTF-16 символ занимать больше 2 байт?
R>>Ещё есть замечательные функции to_utf8/from_utf8. Удивляетесь, что видите их первый раз? Не удивительно, если учесть, что их надо подключать как R>>#include <boost/program_options/detail/convert.hpp> R>>Я никогда не пользовался boost.program_options. Ну так поглядел, для чего она нужна в общих чертах. Но в detail не заглядывал. Однако потребность в такой удобной функции to_utf8 возникала неоднократно.
S>Я попробовал эти функции и понял что они не замечательные. Если wstring хранит строку в UTF-16, а в Windows это именно так, то они должны понимать surrogate pairs.
Можно долго обсуждать, кто виноват в этом -- то ли std::wstring который прямо Unicode не поддерживает, то ли Windows,
то ли еще кто-то, но это как раз вопрос который вполне мог бы всплыть при review, и в худшем случае все могло кончится предложением добавить поддержку всех возможных кодировок Unicode.
А так -- функция в detail, претензии не принимаются
R>... мда, там говориться, что UCS-2 вообще устаревшее понятие. R>Там например идёт речь о символах в диапазоне 100000..10FFFD — это не поместиться в wchar_t.
В виндовый (двухбайтовый) не поместится. В линуксовый (четырехбайтовый) поместится.
R>И всё таки может ли в UTF-16 символ занимать больше 2 байт?
Я уже привел пример L"\xd800\xdc00". Занимает 4 байта, а представляет один character, который называется так:
U+10000 LINEAR B SYLLABLE B008 A
Здравствуйте, saproj, Вы писали:
R>>... мда, там говориться, что UCS-2 вообще устаревшее понятие. R>>Там например идёт речь о символах в диапазоне 100000..10FFFD — это не поместиться в wchar_t. S>В виндовый (двухбайтовый) не поместится. В линуксовый (четырехбайтовый) поместится.
R>>И всё таки может ли в UTF-16 символ занимать больше 2 байт? S>Я уже привел пример L"\xd800\xdc00". Занимает 4 байта, а представляет один character, который называется так: S>U+10000 LINEAR B SYLLABLE B008 A
Ну так значит, всё таки это не UTF-16, я имею в виду в с++ под Windows, потомучто там символы именно 2 байта занимают и не больше и не меньше. fixed-width. Судя потомучто ты сам написал, UTF-16 — это не fixed-width, как я и думал.
R>Ну так значит, всё таки это не UTF-16, я имею в виду в с++ под Windows, потомучто там символы именно 2 байта занимают и не больше и не меньше. fixed-width.
Смотря что ты называешь символами. wchar_t в Windows — 2 байта, однако используемая кодировка — UTF-16, и unicode character занимает 2 или 4 байта.
Возвращаясь к функциям, с которых мы начали, хочу подкинуть тебе следующий факт:
to_utf8 неправильно работает с некоторыми входными данными в то время как WideCharToMultiByte(CP_UTF8, ...) этим не страдает.
Более детальное обсуждение вопроса, боюсь, уже не будет относиться к C++, потому перебираемся в другой форум или завязываем .
Здравствуйте, saproj, Вы писали:
R>>Ну так значит, всё таки это не UTF-16, я имею в виду в с++ под Windows, потомучто там символы именно 2 байта занимают и не больше и не меньше. fixed-width.
S>Смотря что ты называешь символами. wchar_t в Windows — 2 байта, однако используемая кодировка — UTF-16, и unicode character занимает 2 или 4 байта. S>Возвращаясь к функциям, с которых мы начали, хочу подкинуть тебе следующий факт: S>to_utf8 неправильно работает с некоторыми входными данными в то время как WideCharToMultiByte(CP_UTF8, ...) этим не страдает.
Наверное мы говорим о разных вещах. Я говорю о том, что в с++ строки fixed-width. Т.е. функция определения длины строки выглядит как:
size_t wcslen(const wchar_t* sz)
{
size_t l = 0;
while (*sz++) ++l;
return l;
}
Соответственно никакой символ не может занимать 4 байта.
Ты говоришь в Windows. Что это значит?
И кстати как тогда называется кодировка, про которую говорю я? Всё таки UCS-2?
Hello, remark!
You wrote on Thu, 16 Mar 2006 14:26:55 GMT:
DA>> Павел достаточно точно все описал. Если бы ты следил за тем как DA>> развивается буст то вопросов бы просто не было . Что-то появилось DA>> позже, что-то просто одновременно.
r> Я думаю, что одновременно появлялось мало чего. Причина не в этом. r> Позже. Возможно.
Можно и позже и одновременно. Просто Beman Dawes-у нужно было одно, Владимиру чуточку другое. А задерживать выходы очень нужных либ только потому, что они работают, но используют сходный функционал, который можно вынести в отдельную либу, я смысла не вижу. Написанный ими функционал был достаточен для работы их библиотек, поэтому все случилось так как случилось. Если я не прав, пусть Владимир меня поправит.
DA>> Разрабатывали два хороших парня библиотеки и нужно им было с utf8 DA>> поработать. Вот каждый из них сделал себе по штучке. Когда оба прошли DA>> review поняли что у них дубляж. Побубнели друг с другом, поисправляли DA>> баги и остались довольны. И таких примеров там очень много.
r> Я думаю, мало.
А тут думать не нужно. Там их достаточно что бы сказать много. В каждой библиотеке используется какой-то общий и в тоже время имеющие свои реализации функционал. Не раз заводилась речь о том что вот было бы неплохо из этих трех либ повыделять общие части написать пару новых generic библиотек и переписать парочку других уже на них. Люди обменялись опытом как они решили те или иные проблемы, какие приемы применили, обсудили как бы получше, подсказали друг другу что-то новое и .т.д. Но они не начинают тут же выделять что-то в отдельную библиотеку. Просто написание либ не такой простой процесс, а тем более выделение общих частей из уже готовых, да еще с их перепысыванием. Вот когда набирается достаточное количество людей которым этот функционал нужен и сам функционал достаточно устоявшийся и есть люди которые способны выполнить всю работу по перелопачиванию этого добра, вот тогда и делается то чего бы тебе хотелось.
DA>> Что-то выделять начинают только тогда когда это кому-то нужно в DA>> отдельном виде и кто-то может это выделить, написать документацию, DA>> пройти review и еще куча всего. Хотя маленькие либы проходят review DA>> влет, все остальное делается не очень быстро.
r> Большинство вещей, которые я упоминал именно маленькие либы. Это не r> целый serealization или spirit.
Ты выразил желание поиметь маленькие либы, которые сейчас находятся внутри достаточно больших. Даже если эти компоненты полностью отчуждаемы от основной либы, их нужно вытащить оттуда, написать документацию, так как она если и есть то только поверхностная. Всетаки это детали реализации бОльшей либы. Ну и дальше по процессу. Сам понимаешь что может найтись достаточно причин этого не делать. Тем более что для начала нужен спрос на данное действие.
R>Наверное мы говорим о разных вещах. Я говорю о том, что в с++ строки fixed-width. Т.е. функция определения длины строки выглядит как: R>
R>size_t wcslen(const wchar_t* sz)
R>{
R> size_t l = 0;
R> while (*sz++) ++l;
R> return l;
R>}
R>
R>Соответственно никакой символ не может занимать 4 байта.
wcslen так же как и strlen не знает и не должна ничего знать про кодировки.
strlen считает количество байтов. Всегда.
wcslen считает количество wchar_t. Всегда.
R>Ты говоришь в Windows. Что это значит?
Потрудись, пожалуйста, понятно и точно задась свой вопрос.
R>И кстати как тогда называется кодировка, про которую говорю я? Всё таки UCS-2?
То, о чем ты сейчас говоришь, не имеет отношения к кодировкам.
Здравствуйте, saproj, Вы писали:
R>>Наверное мы говорим о разных вещах. Я говорю о том, что в с++ строки fixed-width. Т.е. функция определения длины строки выглядит как: R>>
R>>size_t wcslen(const wchar_t* sz)
R>>{
R>> size_t l = 0;
R>> while (*sz++) ++l;
R>> return l;
R>>}
R>>
R>>Соответственно никакой символ не может занимать 4 байта. S>wcslen так же как и strlen не знает и не должна ничего знать про кодировки. S>strlen считает количество байтов. Всегда. S>wcslen считает количество wchar_t. Всегда.
Тут, возможно, я был не прав и wcslen будет считать правильно имено количество символов.
R>>И кстати как тогда называется кодировка, про которую говорю я? Всё таки UCS-2? S>То, о чем ты сейчас говоришь, не имеет отношения к кодировкам.
Я говорю, о том, что юникод бывает fixed-width и каждый символ в такой кодировке занимает ровно 2 байта, и называется это UCS-2.
Многие писали про дументацию, что типа надо всё документировать. Некоторые из утилит и так задокументированы не хуже, чем основная либа. См. boost.serealization.Miscellaneous
Ещё один аргумент сам придумал, если класть утилиту в корень, а не в detail, то это налагает больше ответственности, т.е. у тулзы должен быть "отточен" интерфейс, т.к. она будет публичная и следовательно её будут юзать и следовательно надо будет поддерживать обратную совместимость. И следовательно над ней придётся подумать гораздо больше, чем просто над утилитой, которую кладёшь к себе в detail.
Ну правда к задокументированным утилитам это не относится, т.к. для них уже придётся поддерживать совместимость.
Но всё-таки до конца у меня не прошло такое чуство, что приложив ещё относительно немного усилий, они могли бы произвести относительно много пользы. Смотрите: код уже есть, код рабочий и отлаженый, т.к. работает в составе какой-то библиотеки, код уже (как я понимаю) прошёл review вместе с библиотекой, код (возможно) уже даже задокументирован. Чего спрашивается ещё надо? По-моему, основное, что осталось — преодалеть бюрократические преграды. Вот тут-то все и забивают.
.
