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

_>Верно. Я, конечно, буст уважаю, но 74 библиотеки? Разве что несколько выбранных наугад.

Не надо выбирать наугад. Обязательно надо Boost.SmartPtr, Boost.Function, Boost.Bind.
Желательно также Boost.Any, Boost.Filesystem, Boost.Statechart, Boost.Regex, Boost.Iostreams.
Плюс всякие мелочи: boost::lexical_cast, boost::noncopyable.

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

C>Да. Вот только в этом коде некий гипотетический тип Utf8 должен быть опять-таки строчкой байт либо достаточно широким символьным типом. А если добавить ещё и обработку диакритики (и соответственно типы Grapheme и GraphemeIterator), то реализация станет сложной, а оптимизация — трудной. Ни о каком произвольном доступе к графемам за O(1), конечно, не стоит и мечтать — разве что индексировать строку при первом использовании…

C>Кстати, в свете юникода стоит отметить ещё одну проблему со строками вообще и со строками в C++ в частности. Строки иногда очень хочется сделать ключом map’а или ещё как-нибудь отсортировать. При этом нужен предикат порядка над строками. А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?

Погоди-погоди. Если я правильно помню, по стандарту в std::wchar_t должен влезать любой символ, который поддерживается реализацией, в том числе суррогатная пара целиком, если реализация заявляет о поддержки оных (я знаю, что у мелкософта это не так — это проблема мелкософта, это значит, что млекософтовский wchat_t на самом деле не поддерживает юникод, со всеми сопутствующими граблями). И вообще когда у тебя есть многобайтовая строка std::string(N), то при помощи codecvt ты можешь получить std::wstring(M), где M<=N, и ее ты уже можешь сравнивать поэлементно.

UPD. Перечитал твои слова. Собственно, ты о том же и говоришь, твой "достаточно широкий символьный тип" — это и есть wchar_t.
А проблемы начинаются, когда у тебя реализация, не поддерживающая тот набор символов, который тебе нужен.

You will always get what you always got
  If you always do  what you always did

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

C> А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?
Для std::map, вообще говоря, естественный язык не важен — там достаточно простого сравнения по кодам символов.

Вот для user-visible сортировок — это да. Но там вообще тааааааааакая "банка с червями".

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

AD>Круто! Я тоже хочу себе пятьдесят четыре довигинтиллиона триста восемь унвигинтиллионов четыреста двадцать восемь вигинтиллионов семьсот девяносто новемдециллионов двести три октодециллиона четыреста семьдесят восемь септендециллионов семьсот шестьдесят два сексдециллиона триста сорок квиндециллионов пятьдесят два кваттуордециллиона семьсот двадцать три тредециллиона триста сорок шесть дуодециллионов девятьсот восемьдесят три ундециллиона четыреста пятьдесят три дециллиона четыреста восемьдесят семь нониллионов двадцать три октиллиона четыреста восемьдесят девять септиллионов девятьсот восемьдесят семь секстиллионов двести тридцать один квинтиллион двести семьдесят пять квадриллионов четыреста двенадцать триллионов триста девяносто миллиардов восемьсот семьдесят два миллиона триста сорок восемь тысяч четыреста семьдесят пять байтов оперативы

Жаверам это скажи
Это у них на каждом шагу OutOfMemoryException

You will always get what you always got
  If you always do  what you always did

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

C>> А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?
C>Для std::map, вообще говоря, естественный язык не важен — там достаточно простого сравнения по кодам символов.
Вобще, как я понял предыдущего оратора, он утверждает что "в общем случае не сводится к поэлементному сравнению ". Те прямо противоположное твоему утверждению.
Честно говоря первый раз такое слышу Пока читаю ссылки данные им.

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

RO>Я бы рассказал про итераторы, всё равно большинство людей их до конца, похоже, не осилило. Например, почему std::reverse(str.begin(), str.end()) — неверный ответ на вопрос «как развернуть строку». По этому поводу есть две поучительные

Автор: Odi$$ey
Дата: 14.03.03

картинки

Автор: Roman Odaisky
Дата: 26.03.07

.

картинки конечно поучительные, однако не совсем верные.
дело в том, что по стандарту разрешено указавать на 1 элемент после последнего.
выход за диапазоны приводит к UB. ссылаться на элемент перед начальным -- UB.

поэтому в стандартной либе извращаются таким вот образом

template<typename _Iterator> class reverse_iterator
{
    protected:
      _Iterator current;

    public:

      iterator_type base() const { return current; }

      reference operator*() const {
    _Iterator __tmp = current;
    return *--__tmp;
      }
};

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

J>Погоди-погоди. Если я правильно помню, по стандарту в std::wchar_t должен влезать любой символ, который поддерживается реализацией, в том числе суррогатная пара целиком, если реализация заявляет о поддержки оных (я знаю, что у мелкософта это не так — это проблема мелкософта, это значит, что млекософтовский wchat_t на самом деле не поддерживает юникод, со всеми сопутствующими граблями). И вообще когда у тебя есть многобайтовая строка std::string(N), то при помощи codecvt ты можешь получить std::wstring(M), где M<=N, и ее ты уже можешь сравнивать поэлементно.

Не, ну если тебе надо чтобы было "стандартно", а не чтобы "работало", то таки да, ты прав.

Конечно Windows давнои хмуро нестандартна по многим направлениям. ИМХО это заслуга, как M$, так и держателей стандартов, потому что держатели нифига не мохают расширять свои стандарты и не думать о примественности. Но MS тут конечно намного больше старается на нестандартность. ИМХО это даже обсуждать смысла никакого.
Проблема в том, что Windows давно уже может наплевать на то, что она "нестандартна". Ей это не особо-то и надо...
Это нам всем надо, чтобы под Windows тоже работало

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

Q>Желательно также Boost.Any, Boost.Filesystem, Boost.Statechart, Boost.Regex, Boost.Iostreams.

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

E>Не, ну если тебе надо чтобы было "стандартно", а не чтобы "работало", то таки да, ты прав.

Ну под Linux в wchar_t влезает чуть ли не UTF-32, если мне память не изменяет.

На самом деле все стандартно и под линухом, и под виндой.
Просто под линухом поддержка уникода лучше, чем под виндой.

А это значит, что под линухом ты можешь пользоваться стандартной строкой, а под виндой тебе нужен бубен расписной.
Ну и естественно, если понадобится поддержка уникода, который не влезет в линуховый — там потребуется тот же бубен.

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

E>Это нам всем надо, чтобы под Windows тоже работало
Мне, например, не надо

You will always get what you always got
  If you always do  what you always did

>А Boost.Any зачем? (-)

А почему нет? Чем вам Boost.Any не угодил? Отличная маленькая аккуратная библиотечка. boost::any отлично заменяет шарповский System.Object. Гораздо безопасее, чем void*. Удобнее, чем весь-из-себя-статический Boost.Variant.

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

E>>Это нам всем надо, чтобы под Windows тоже работало
J>Мне, например, не надо

Ну "нам" -- этоимелось в виду "сообществу программистов и их клиентам"

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

Q>А почему нет? Чем вам Boost.Any не угодил? Отличная маленькая аккуратная библиотечка. boost::any отлично заменяет шарповский System.Object. Гораздо безопасее, чем void*. Удобнее, чем весь-из-себя-статический Boost.Variant.

Ну нужда редкая довольно. Обычно если полиморфизм нужен, то он по честному по приплюснутому организуется...

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

E>Ну нужда редкая довольно. Обычно если полиморфизм нужен, то он по честному по приплюснутому организуется...

Редкая, согласен. И насчёт «обычно по-честному организуется» тоже согласен. Просто обычно нужен не абстрактный абстрактный System.Object, а конкретный абстрактный SomeFunctionArgs  Но в некоторых случаях boost::any очень удобен.

В этот список «чего надо выучить» я внёс Boost.Any из-за того, что там учить нечего — 10 минут надо читать доки, ещё 10 минут потратить на изучение исходников (это полезно, реализация там прозрачная и внятная). И всё, можно использовать.

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

Q>В этот список «чего надо выучить» я внёс Boost.Any из-за того, что там учить нечего — 10 минут надо читать доки, ещё 10 минут потратить на изучение исходников (это полезно, реализация там прозрачная и внятная). И всё, можно использовать.


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

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

E>ИМХО вред от Boost.Any не в том, что его долго изучать, а в том, что в нормальной программе его не должно быть нужно.

Он может быть даже в «нормальной» программе. Например, если вы читаете данные из файла. Я видел реализацию аналогичного класса Value в библиотеке Exiv2. Лучше бы авторы взяли boost::any, ей богу. Удобно также использовать streamable any.

E>Короче это только очень продвинутым людям нужно изучать, а не тем, кто про умные указатели не в курсе

Это да, вначале умные указатели, остальное потом. Я ещё Boost.Tuples забыл, его тоже можно включить в список «желательно» (не «обязательно»).

Итоговое имхо насчёт сабжа всей ветки: начинающим в Boost'е надо выучить ровно три библиотеки. В этом ничего сложного нет, освоить их можно за три дня (чтение доков, написание sandbox'ов и helloworld'ов). Об остальных библиотеках прочитать в общих чертах (ещё полчаса) и подучивать по мере необходимости (не раньше .

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

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

E>>>Это нам всем надо, чтобы под Windows тоже работало
J>>Мне, например, не надо

E>Ну "нам" -- этоимелось в виду "сообществу программистов и их клиентам"

А-а-а... Ну моим клиентам пофиг, на чем сервер написан и на какой оси он крутится

You will always get what you always got
  If you always do  what you always did

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

RO>>Я бы рассказал про итераторы, всё равно большинство людей их до конца, похоже, не осилило. Например, почему std::reverse(str.begin(), str.end()) — неверный ответ на вопрос «как развернуть строку». По этому поводу есть две поучительные

Автор: Odi$$ey
Дата: 14.03.03

картинки

Автор: Roman Odaisky
Дата: 26.03.07

.

NB>картинки конечно поучительные, однако не совсем верные.
NB>дело в том, что по стандарту разрешено указавать на 1 элемент после последнего.

Я знаю. Вроде Одиссей всё правильно нарисовал. Там стрелочки указывают на то, на что укажет &*, а черточки, с которых стрелочки начинаются, — на сам итератор (или base() для reverse_iterator).

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

RO>Я знаю. Вроде Одиссей всё правильно нарисовал. Там стрелочки указывают на то, на что укажет &*, а черточки, с которых стрелочки начинаются, — на сам итератор (или base() для reverse_iterator).

внутренний голос говорит, что такие пляски с указателями не совсем хорошо скажутся на производительности.
может вариант с std::reverse окажется получше... тестить надо.

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

_>Очень интересно мнение форумчан, насколько широко люди, программирующие на С++, используют boost & STL? Речь идет о самом широком срезе -- студенты, программисты, хобби-девелоперы...


есть мнение, что человек не знающий boost, а тем более stl- с++ не знает.
исключения конечно придумать можно.. но правило 80-20 тут применимо- стопудова.