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

A>Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.

А когда вас навещает мелкий пушной зверёк, вы с удивлением замечаете, что разобраться в том что используете, вы уже не в состоянии, а отладчик, на проcьбу показать где же мы упали и что у нас в памяти, показывает вам большую смачную фигу .... вот значится какой ты северный олень.. тфу ты, серебрянная пуля, значится.

P.S.
Это не оффтоп, это на правах необходимой ложки дегтя.

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

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

A>>Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.

AC>А когда вас навещает мелкий пушной зверёк, вы с удивлением замечаете, что разобраться в том что используете, вы уже не в состоянии, а отладчик, на проcьбу показать где же мы упали и что у нас в памяти, показывает вам большую смачную фигу .... вот значится какой ты северный олень.. тфу ты, серебрянная пуля, значится.

Пушные зверьки разные бывают. Здесь речь, видимо, о белочке...

AC>P.S.
AC>Это не оффтоп, это на правах необходимой ложки дегтя.

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

F>Пушные зверьки разные бывают. Здесь речь, видимо, о белочке...


Ну, к кому кто приходит. К кому-то и белочка. Я же говорил про народного любимца — песца.

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

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

A>>Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.

AC>А когда вас навещает мелкий пушной зверёк, вы с удивлением замечаете, что разобраться в том что используете, вы уже не в состоянии, а отладчик, на проcьбу показать где же мы упали и что у нас в памяти, показывает вам большую смачную фигу .... вот значится какой ты северный олень.. тфу ты, серебрянная пуля, значится.

Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.

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

A>Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.
Кривой — не кривой, dbx, например, кривой отладчик? Он с STL-ем то не дружит, а вы — буст. А буст это ведь не только умные указатели.

То есть ты хочешь сказать, что по корке (краш дампу) легко восстановишь состояние сигналов и функторов? Определишь, например, что сломалось в коде активно пользующем препроцессор и mpl? Ну и т.д... Тогда ты просто зверь!!! Могу только позавидовать. Если нет, то либо вы пользуете, то, для чего буст нафиг не нужен, либо готовите угощение для белочки, которая несомненно придет вслед за песцом.

Хотя, есть еще два варианта. Вы не пользуете никакого библа кроме стандартного, впринципе не ошибаетесь и в вашем коде не возможны ошибки второго рода (надо заметить, что даже в стандартной библе есть ошибки). Или ваша программа не особенно сложнее hello_world. Однако, тоже вариант.

Я говорю лишь о том, что boost — это конечно круто, но слишком замудрёно для тех задач, для которых его часто пытаются использовать. ИМХО, достоинства его весьма сомнительны, разве что для развития мыслительного процесса, но это уже академическое программирование. И используют его, почему-то веря в то, что не придется копаться в его внутренностях. Если повезет не придется, если не повезет, то завистит от уровня девелоперов.

Плюсы это ведь не ява и не до-диез. Для плюсов успешность таких фокусов зависит лишь от везения и опыта.

P.S.
Почему я вообще ввязался вэтот флейм?
Задолбало на каждом углу слышать — BOOST! Ура! Мега польза и никаих недостатков!
Причем не от опытных спецов, а _в_основном_ от людей делающих свой первый 'крупный-коммерческий-проект'

Если я сам советую всем, кто спрашивает — 'а использовать ли STL', — да ОБЯЗАТЕЛЬНО использовать! То про BOOST я того же сказать не могу. Скорее могу сказать — НЕ ИСПОЛЬЗОВАТЬ, пока сами не сможете сделать то же самое.

Добро пожаловать в увлекательный и загадочный мир C++.

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

AC>Добро пожаловать в увлекательный и загадочный мир C++.

в принципе я со всем согласен, я не являюсь достаточно опытным девелопером в разработке крупных проектов, но как-то решил прикрутить себе в уже существующий проект boost::filesystem, думал будет удобно ... граблей было немало ... в итоге я отказался, boost весьма хороша, но без необходимости юзать ее больше не собираюсь ...

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

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

A>>Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.
AC>Кривой — не кривой, dbx, например, кривой отладчик? Он с STL-ем то не дружит, а вы — буст. А буст это ведь не только умные указатели.

Под AIX? Как он может с STL не дружить. Пользуй тогда лучше gdb.

AC>То есть ты хочешь сказать, что по корке (краш дампу) легко восстановишь состояние сигналов и функторов?

Восстановлю.

>Определишь, например, что сломалось в коде активно пользующем препроцессор и mpl? Ну и т.д... Тогда ты просто зверь!!! Могу только позавидовать. Если нет, то либо вы пользуете, то, для чего буст нафиг не нужен, либо готовите угощение для белочки, которая несомненно придет вслед за песцом.

А чем сложнее шаблонный код нешаблонного в смысле отладки7 Да не чем. Когда я отлаживаюсь мне важен object layout. А это мне любой отладчик покажет. А если ты еще и сможешь сказать как на стеке параметры располагаются и построить приблизительные предположения где какой inline произошел, то ничего тебе (т.е. мне) не страшно.

Гораздо неприятнее когда у тебя куча макросов генериющих код. Это значит люди прото не знали, как тоже самое можно сделать шаблонами гораздо красивее и легче отлаживать кстати. А самый большой прикол, это когда у тебя данные по отрицательному смещению расположены. Вот это круто! Пойди догадайся называется. Какой тут boost, в нем такой ерунды нет.

AC>Хотя, есть еще два варианта. Вы не пользуете никакого библа кроме стандартного, впринципе не ошибаетесь и в вашем коде не возможны ошибки второго рода (надо заметить, что даже в стандартной библе есть ошибки). Или ваша программа не особенно сложнее hello_world. Однако, тоже вариант.

AC>Я говорю лишь о том, что boost — это конечно круто, но слишком замудрёно для тех задач, для которых его часто пытаются использовать. ИМХО, достоинства его весьма сомнительны, разве что для развития мыслительного процесса, но это уже академическое программирование. И используют его, почему-то веря в то, что не придется копаться в его внутренностях. Если повезет не придется, если не повезет, то завистит от уровня девелоперов.

AC>Плюсы это ведь не ява и не до-диез. Для плюсов успешность таких фокусов зависит лишь от везения и опыта.

AC>P.S.
AC>Почему я вообще ввязался вэтот флейм?
AC>Задолбало на каждом углу слышать — BOOST! Ура! Мега польза и никаих недостатков!
AC>Причем не от опытных спецов, а _в_основном_ от людей делающих свой первый 'крупный-коммерческий-проект'

AC>Если я сам советую всем, кто спрашивает — 'а использовать ли STL', — да ОБЯЗАТЕЛЬНО использовать! То про BOOST я того же сказать не могу. Скорее могу сказать — НЕ ИСПОЛЬЗОВАТЬ, пока сами не сможете сделать то же самое.

Ты сделаешь тоже самое, твой сосед по офису сделает тоже самое, и пара десятков других программистов сделают это-же самое только на их собственный лад. А потеха потом с разбирательством в этом всем коде не хилая.

AC>Добро пожаловать в увлекательный и загадочный мир C++.

Мне не нужно приглашение.

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

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

A>>Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.
AC>Кривой — не кривой, dbx, например, кривой отладчик? Он с STL-ем то не дружит, а вы — буст. А буст это ведь не только умные указатели.

кривой
по крайней мере, та его версия, что используется у нас.

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

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

AC>Если я сам советую всем, кто спрашивает — 'а использовать ли STL', — да ОБЯЗАТЕЛЬНО использовать! То про BOOST я того же сказать не могу. Скорее могу сказать — НЕ ИСПОЛЬЗОВАТЬ, пока сами не сможете сделать то же самое.

Насчет STL можно поспорить. Как развивался STL? Русский чувачок Степанов сделал "Stepanov Template Library" для конкретного компилятора и конкретной платформы. Страусу Трупу это дело очень понравилось и он все описал в своей книжке. Но кроме этого, обнаружились некие деятели из Microsoft, которые решили сказать, что "а у нас тоже типа вот". Типа STL, C++, все круто. Но оказалось, что исходники Степанова ихним компилятором просто не компилируются. Ну это же плохие исходники! Не править же нам из за какого-то там Степанова свой мега-компилятор! Ну и что с того, что с ним Страуструп дружит?! У нас собственное вИдение. И вот взяли они книжку Страуструпа и по ней забубенили имплементацию в соответствии со своим корпоративным мега-стандартом. Вообще-то, никакого кода они не писали, они взяли тексты некого P.J. Plauger из HP и поправили их чуток. Ну совсем чуток, чтобы хотя бы компилировалось. И получилось вот такая вот тоже STL. Едрёныть. Фиг с ним, что на практике там больше граблей чем пользы, но ведь зато STL! И вот пока такие криворукие имплементации существуют и более того, широко распространены, лично я использую STL с очень большой оглядкой. Буст в этом смысле даже лучше, в нем изначально учтены особенности убогих компиляторов. Но в этом же и грабли. Получается слишком много условной компиляции, которая делат код нечитабельным. Короче говоря, ну в общем вы поняли. Я просто гоню, наслушавшись Шендеровича

AC>Добро пожаловать в увлекательный и загадочный мир C++.

Я бы сказал шире и проще — добро пожаловать в наш говённый мир...

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

A>>>Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.
AC>>Кривой — не кривой, dbx, например, кривой отладчик? Он с STL-ем то не дружит, а вы — буст. А буст это ведь не только умные указатели.

J>кривой
J>по крайней мере, та его версия, что используется у нас.
Нее... Он ограничен и специфичен. Чтобы сказать что он крив, его надо с чем-то сравнить. С чем, с gdb? Дык про него тоже самое сказать можно Как впрочем и про VS. Все ведь зависит от точки зрения.... В WinDBG тоже STL как-то не прёт дебажить, а ловить действительно серезные ошибки в отладчике от VS... ну-ну, удачного полета тем, кто это решится делать.

Вот Sun C++ кривой компилер? Я бы сказал специфический. Что же сделаешь, если окромя него код под многопроцессорный спарк писать фактически не на чем. Да и хоть какой-то тул по профайлингу присутствует. Gcc? Ой, спасибо, накушались. Скупой, как известно, платит дважды.

В этом, собственно, и заключается отличие от академического программирования, когда можно выбрать любую платформу и поюзать любую понравившуюся среду разработки, приципив любую гору знакомого гомна, да еще и писать/отлаживать в тепличных условиях.

Чисто для примера... (пример для gdb'а, но для dbx'а такая же ....)
Удаляем из map'a элемент и прога падает (это еще повезло что сразу упала). Смотрим что произошло...

(gdb) where
#0  std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&, std::_Rb_
tree_node_base*&, std::_Rb_tree_node_base*&) (
    __z=0x3d23d8, __root=@0x3d23dc, __leftmost=@0x3d23e0,
    __rightmost=@0x3d23e4) at g:/MinGw/include/c++/3.2.3/bits/stl_tree.h:484
#1  0x0040147a in main () at g:/MinGw/include/c++/3.2.3/bits/stl_tree.h:1169
(gdb) f 1
#1  0x0040147a in main () at g:/MinGw/include/c++/3.2.3/bits/stl_tree.h:1169
1169          _Link_type __y =
(gdb) p this
$1 = (
    map<int,int,std::less<int>,std::allocator<std::pair<const int, int> > > * const) 0x0
(gdb) list
1164      template<typename _Key, typename _Val, typename _KeyOfValue,
1165               typename _Compare, typename _Alloc>
1166        inline void
1167        _Rb_tree<_Key,_Val,_KeyOfValue,_Compare,_Alloc>::erase(iterator __position)
1168        {
1169          _Link_type __y =
1170            (_Link_type) _Rb_tree_rebalance_for_erase(__position._M_node,
1171                                                      _M_header->_M_parent,
1172                                                      _M_header->_M_left,
1173                                                      _M_header->_M_right);
(gdb) p __position
$2 = {<_Rb_tree_base_iterator> = {_M_node = 0x3d23d8}, <No data fields>}

Зорово да? Кто может сказать, что это за нода которую мы удаляем? А кто может сказать какие данные лежат в мапе?
Ладно, допустим я знаю как реализован мап...

(gdb) p * (_Rb_tree_node<std::pair<const int, int> > *)__position._M_node
$6 = {<_Rb_tree_node_base> = {_M_color = _M_black, _M_parent = 0x3d2408,
    _M_left = 0x3d2438, _M_right = 0x3d2450}, _M_value_field = {first = 0,
    second = 0}}

И что мне это может сказать?
Хорошо у меня такого элемента вообще в мапе не должно быть и я могу понять, что удаляю я что-то не то...

посмотрим что у нас в дереве...

(gdb) p this
$16 = (
    map<int,int,std::less<int>,std::allocator<std::pair<const int, int> > > * const) 0x0

Упс... а вот и особенность релизной сборки. Приплыли?

Пример сделан на виндовом gdb, на солярке я так и не смог добиться на простом примере, чтобы упало там где ошибка, падало все время где-то в другом месте. Это любителям юзать стандартные либы. Или вы никогда не ошибаетесь?

На салярке получается вот такая корка. Падает на деструкторе.

...
  [74] __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,
std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X>,
__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X>,
std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,
std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,
std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X> > >
::__erase(0x8047bc0, 0x8083040), at 0x80528a5
...
  [100] __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,
std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X>,
__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X>,
std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,
std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,
std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,X> > >
::__erase(0x8047bc0, 0x8063248), at 0x80528a5

Здравствуйте, Аноним, Вы писали:

А> Русский чувачок Степанов сделал "Stepanov Template Library"

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

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

A>>>>Что у вас там за отладчик кривой? Наш отладчик всегда всё показывает. Это для нас наименьшая из проблем.
AC>>>Кривой — не кривой, dbx, например, кривой отладчик? Он с STL-ем то не дружит, а вы — буст. А буст это ведь не только умные указатели.

J>>кривой
J>>по крайней мере, та его версия, что используется у нас.
AC>Нее... Он ограничен и специфичен. Чтобы сказать что он крив, его надо с чем-то сравнить. С чем, с gdb? Дык про него тоже самое сказать можно :) Как впрочем и про VS. Все ведь зависит от точки зрения.... В WinDBG тоже STL как-то не прёт дебажить, а ловить действительно серезные ошибки в отладчике от VS... ну-ну, удачного полета тем, кто это решится делать.

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

AC>Вот Sun C++ кривой компилер? Я бы сказал специфический. Что же сделаешь, если окромя него код под многопроцессорный спарк писать фактически не на чем.

Кривой, конечно.
Но действительно, ничего не поделаешь.
Раз уж сану жалко бабла на нормальный front-end. На back-end, в общем-то, наездов от меня нет, но его front-end — это недоразумение какое-то. В общем-то, и сами его разработчики это признают (есть у меня знакомые там), но эти самые разработчики занимаются исключительно оптимизацией. Такое впечатление, что на front-end сан просто забил. Потому что компилятор, не поддерживающий ковариантные возвращамые значения и не делающий банальной проверки наличия return во всех control paths функции — это какой-то очень недокомпилятор.

AC>В этом, собственно, и заключается отличие от академического программирования, когда можно выбрать любую платформу и поюзать любую понравившуюся среду разработки, приципив любую гору знакомого гомна, да еще и писать/отлаживать в тепличных условиях.

AC>Чисто для примера... (пример для gdb'а, но для dbx'а такая же ....)
AC>Удаляем из map'a элемент и прога падает (это еще повезло что сразу упала). Смотрим что произошло...

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

Тебе достаточно знать, что есть 2 объекта — мапа и какой-там-тип-у-твоего-элемента, и что прога падает — больше ты ничего из корки осмысленного не вытащишь, разве что тебе сильно-сильно повезет.

Заодно скажу, что в нашем случае (в том, который я обсуждал в твоем эмоциональном топике про буст), так как нет шаблонов и все генерится макросами, вообще от отладчика толку 0.

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

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

J>пример скипнут, потому что ты уже написал, что произошло. Все, на это миссия отладчика, по крайней мере в режиме разбора корки, окончена.
Ты не впилил, как говорит моя благоверная
Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

J>Дальше — вперед, в исходники, с линейкой и циркулем.
J>более того, твой пример даст точно такую же каку и без шаблонов.
J>Ну покажешь ты пальчиком в конкретное место в дизассемблированного кода, который обрушивае программу — и что?
Уууу.... мне это очень много скажет Вместе дампом памяти, естественно. Только уж очень тяжко потраха STL'я копать.

J>Тебе достаточно знать, что есть 2 объекта — мапа и какой-там-тип-у-твоего-элемента, и что прога падает — больше ты ничего из корки осмысленного не вытащишь, разве что тебе сильно-сильно повезет.
На самом деле вытащу, но предпочитаю свои контейнеры юзать, из которых это вытащить существенно проще. Как показывает проктика можно писать код так, что по корке вполне можно отловить баг. Да и на нескольких процессорах баги весьма тяжело воспроизводить.Уж очень они могут неуловимыми быть.

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

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

J>>пример скипнут, потому что ты уже написал, что произошло. Все, на это миссия отладчика, по крайней мере в режиме разбора корки, окончена.
AC>Ты не впилил, как говорит моя благоверная :)
AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

И как, поймали?
В двух словах — в чем было дело? Только честно.

J>>Дальше — вперед, в исходники, с линейкой и циркулем.
J>>более того, твой пример даст точно такую же каку и без шаблонов.
J>>Ну покажешь ты пальчиком в конкретное место в дизассемблированного кода, который обрушивае программу — и что?
AC>Уууу.... мне это очень много скажет :) Вместе дампом памяти, естественно. Только уж очень тяжко потраха STL'я копать.

Может, мне не везло капитально всю мою жизнь, но если мне приходилось разбираться в корке, память там была уже в настолько неузнаваемом состоянии, чтооставалось только руками разводить.
Т.е. вот оно все как на ладони, в %l0 положили то, в %o1 — сё, вот он доступ по левому адресу — нет там никакого объекта (либо вот он доступ по нормальному адресу, но объект в невменяемом состоянии), вот здесь все и обрушилось
Только проблема обычно сработала гораздо раньше, и с 90% вероятностью ты это место не найдешь, рассматривая корку.

J>>Тебе достаточно знать, что есть 2 объекта — мапа и какой-там-тип-у-твоего-элемента, и что прога падает — больше ты ничего из корки осмысленного не вытащишь, разве что тебе сильно-сильно повезет.
AC>На самом деле вытащу, но предпочитаю свои контейнеры юзать, из которых это вытащить существенно проще. Как показывает проктика можно писать код так, что по корке вполне можно отловить баг. Да и на нескольких процессорах баги весьма тяжело воспроизводить.Уж очень они могут неуловимыми быть.

Да. Но мое мнение — дебаггер тут мало поможет. Разве что ты нашел баг в кодогенераторе компилятора, но тогда баг будет стабильно воспроизводиться.

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

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

AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

Я это себе поставлю в origin.

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

AC>>Ты не впилил, как говорит моя благоверная
AC>>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

J>И как, поймали?
J>В двух словах — в чем было дело? Только честно.
Был мап с элементами, и список по которому они удалялись. По логике в список один элемент попадать два раза не должен был, но таки попал... в совершенно непредсказуемой ситуации, которая никогда не должна была случится. Почему для мапа не сделали проверку на удаление end, для меня загадка.

J>Может, мне не везло капитально всю мою жизнь, но если мне приходилось разбираться в корке, память там была уже в настолько неузнаваемом состоянии, чтооставалось только руками разводить.

Мне иногда по одному стек-трейсу и кусочку стека баги ловить приходится. Без дампа памяти.

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

G>

AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

G> Я это себе поставлю в origin.

А в чем поинт?

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

А>> Русский чувачок Степанов сделал "Stepanov Template Library"

ssm>

А чего здесь смешного? По слухам именно так изначально STL и расшифровывалась. Это уже потом, когда к Степанову присоединились David Musser и Meng Lee, он из скромности переименовал свое творение в "Standard Template Library".

STL was started by Alexander Stepanow at HP in 1979.

Как время летит! STLю уже 25 лет, но усилиями Microsoft она до сих пор крива.

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

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

G>>

AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

G>> Я это себе поставлю в origin.

AC>А в чем поинт?
В эффекте, производимом на неподготовленного слушателя!

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

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

А>>> Русский чувачок Степанов сделал "Stepanov Template Library"

ssm>>

MS>А чего здесь смешного? По слухам именно так изначально STL и расшифровывалась. Это уже потом, когда к Степанову присоединились David Musser и Meng Lee, он из скромности переименовал свое творение в "Standard Template Library".

прикольная теория, я вчера долго смеялся. вчера пытался рассмешить немца-соседа, но он мне сказал — das ist doch logisch(мля, так этожежь логично, ели-пали). ты случаем не немес?

MS>

MS>STL was started by Alexander Stepanow at HP in 1979.

MS>Как время летит! STLю уже 25 лет, но усилиями Microsoft она до сих пор крива.

при чем тут Microsoft вообще к стандартной библиотеке степанова?

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


AC>Был мап с элементами, и список по которому они удалялись. По логике в список один элемент попадать два раза не должен был, но таки попал... в совершенно непредсказуемой ситуации, которая никогда не должна была случится. Почему для мапа не сделали проверку на удаление end, для меня загадка.

Дык я че-то не понял — кто виноват-то? СТЛ или программер, который не поставил проверки на дубликаты ключей и на наличие/отсутсвие элемента в мапе?

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

ssm>das ist doch logisch(мля, так этожежь логично, ели-пали)

грамотный перевод

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

G>>>

AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.

G>>> Я это себе поставлю в origin.
AC>>А в чем поинт?
G> В эффекте, производимом на неподготовленного слушателя!

Ну что ты, до перла — "продам маму и мозги" — мне далеко

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


MS>Как время летит! STLю уже 25 лет, но усилиями Microsoft она до сих пор крива.

А в чем MS виновата?

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

AC>>Был мап с элементами, и список по которому они удалялись. По логике в список один элемент попадать два раза не должен был, но таки попал... в совершенно непредсказуемой ситуации, которая никогда не должна была случится. Почему для мапа не сделали проверку на удаление end, для меня загадка.

G>Дык я че-то не понял — кто виноват-то? СТЛ или программер, который не поставил проверки на дубликаты ключей и на наличие/отсутсвие элемента в мапе?

Тот кто логику своим фиксом сломал

Да никто не виноват на самом деле. Такой ситуации вообще быть не должно было. Но вот случилась. А в любой программе подобных, именно логических ошибок дофига. Только пока язык разработки Java, C# и даже Eiffel — проблем нет, но в C++ такие ошибки могут иметь колоссальные последствия.

Тема то о том, что ловить потом такие ошибки, которые так просто-то и не воспроизведёшь, очень тяжело. Причем в, типа, 'надежном' коде, надежность которого обеспечивается через STL/BOOST. А мега 'простой' код BOOST'а, да и STL'я впрочем тоже, только затрудняет этот процесс.

Я лишь привел пример который случился совсем недавно. Можно и много других привести. Например опечатка в цикле по итератору вектора, где начало от одного контейнера, а конец от другого. Может сразу свалиться, а может через год стабильной работы. Интересно, не правда ли?

P.S.

Почему для map'а не сделали проверку на совешенно очевидную ошибку, вероятность возникновения которой в большом проекте близка к единице, мне действительно непонятно.

Кстати вопрос любителям стл, допустима ли конструкция cont.erase(remove(cont.begin(),cont.end(),val),cont.end())? А конструкция cont.erase(find(cont.begin(),cont.end(),val))? Мне интерсно, откуда такая обалденная логичность и надежность

ИМХО, STL так же надежен (в рамках примеров из книжек), как и BOOST решает реальные проблемы (которые его авторы сами себе придумали).

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



G>>Дык я че-то не понял — кто виноват-то? СТЛ или программер, который не поставил проверки на дубликаты ключей и на наличие/отсутсвие элемента в мапе?

AC>Тот кто логику своим фиксом сломал

AC>Да никто не виноват на самом деле. Такой ситуации вообще быть не должно было. Но вот случилась. А в любой программе подобных, именно логических ошибок дофига. Только пока язык разработки Java, C# и даже Eiffel — проблем нет, но в C++ такие ошибки могут иметь колоссальные последствия.

Хм.. Это ваще уже какие-то дремучие религиозные рассуждения пошли. Язык рояли не грает. Играет рояль тот, кто на нем пишет.

AC>Тема то о том, что ловить потом такие ошибки, которые так просто-то и не воспроизведёшь, очень тяжело. Причем в, типа, 'надежном' коде, надежность которого обеспечивается через STL/BOOST. А мега 'простой' код BOOST'а, да и STL'я впрочем тоже, только затрудняет этот процесс.

То ест ья так понял ты рассжудаешь тут о том что ловить семантические ошибки тяжело? Ну а кто ж спорит. Тока буст тут при чем — яне пойму. Шо, буст, шо стл, шо мфц — это просто набор инструментов. Не хочешь — не пользуйся. Если ошибка в самой библиотеке — это одно, если же в логике программы — это совсем другое.

AC>Я лишь привел пример который случился совсем недавно. Можно и много других привести. Например опечатка в цикле по итератору вектора, где начало от одного контейнера, а конец от другого. Может сразу свалиться, а может через год стабильной работы. Интересно, не правда ли?

Ага ОЧень интересно То есть делаем вывод что итераторы плохи?

AC>P.S.

AC>Почему для map'а не сделали проверку на совешенно очевидную ошибку, вероятность возникновения которой в большом проекте близка к единице, мне действительно непонятно.

От объема прожекта наличие или отсутвсвие ошибки не зависит. Тем более такой.

AC>Кстати вопрос любителям стл, допустима ли конструкция cont.erase(remove(cont.begin(),cont.end(),val),cont.end())? А конструкция cont.erase(find(cont.begin(),cont.end(),val))? Мне интерсно, откуда такая обалденная логичность и надежность

Тип у cont какой?

AC>ИМХО, STL так же надежен (в рамках примеров из книжек), как и BOOST решает реальные проблемы (которые его авторы сами себе придумали).

Слава богу что имхо.

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

G>Хм.. Это ваще уже какие-то дремучие религиозные рассуждения пошли. Язык рояли не грает. Играет рояль тот, кто на нем пишет.
Ага, конечно. Что меня радует в студентах и некоторых людях недавно окончевших вуз, как в прочем и прочитавших книжку C++ за 24 часа, так это непонимание того, что С++ это язык незащищающий программиста от платформы. И __любая__ ошибка программиста, пусть он будет хоть супер гигант от прогроаммировния, может привести к ситуации, в которой эту ошибку можно будет искать годами. В общем-то и писать на нем надо по другому чем на C#, Java, и т.д. А так, конечно, от языка ну ничего не зависит...

G>То ест ья так понял ты рассжудаешь тут о том что ловить семантические ошибки тяжело? Ну а кто ж спорит. Тока буст тут при чем — яне пойму. Шо, буст, шо стл, шо мфц — это просто набор инструментов. Не хочешь — не пользуйся. Если ошибка в самой библиотеке — это одно, если же в логике программы — это совсем другое.
Ну не надо, про тоже самое, что и MFC и другие STL — это часть языка, и от тебя вправе требовать его знание. Ещё последнее время почему-то считается, что каждый должен знать и пользовать BOOST. Но несмотря на свою 'стандартность', эти библиотеки могут помочь для написания hello_world или студенту при изучении языка, в нормальном проекте от них вреда не меньше чем пользы

AC>>Например опечатка в цикле по итератору вектора, где начало от одного контейнера, а конец от другого....
G>Ага ОЧень интересно То есть делаем вывод что итераторы плохи?
Нет делаем вывод, что миф о _надежности_ STL'я — это именно миф. Про удобство использования я вообще молчу. Какие еще у него плюсы, а какие плюсы у BOOST'а?

AC>>ИМХО, STL так же надежен (в рамках примеров из книжек), как и BOOST решает реальные проблемы (которые его авторы сами себе придумали).
G>Слава богу что имхо.
Дык тебе никто и не мешает огребстись граблей... потом, когда пройдет релиз... если тебя это конечно коснётся.

А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был.

Ага! Все-таки русский.

I was born in Moscow, USSR, on November 16, 1950, and studied Mathematics at the Moscow State University

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

L_L>А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был.
Ты что, не читал, как он рыбой отравился, в результате чего в горячечном бреду родилась STL?

http://www.rsdn.ru/Forum/?mid=16763

Автор: Brother
Дата: 11.12.01

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

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

L_L>>А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был.
R>Ты что, не читал, как он рыбой отравился, в результате чего в горячечном бреду родилась STL?

R>http://www.rsdn.ru/Forum/?mid=16763

Автор: Brother
Дата: 11.12.01

Ссылка на оригинальную статью не открывается, увы

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

L_L>А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был.

здесь

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

R>Ты что, не читал, как он рыбой отравился, в результате чего в горячечном бреду родилась STL?

Как раз в Гугле нашел, читаю

P>Ссылка на оригинальную статью не открывается, увы

http://www.stlport.org/resources/StepanovUSA.html

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

MS>>Как время летит! STLю уже 25 лет, но усилиями Microsoft она до сих пор крива.

AJD>А в чем MS виновата?

Тем, что им надо было дорабатывать свой компилятор и приводить его в соответствии со стандартом C++. После чего брать исходники STL и поставлять ничего не исправляя. Но они испортили STL (причем всяли весьма древнюю версию), понавставляли затычек, что-то пообкусали и т.д. Получилась кастрированная версия, в которой очень много граблей. Да хоть с теми же статическими переменными в std::map. Реалии таковы, что народ до сих пор пользуется VC6, а иногда — даже VC5 и с этим приходится считаться (мне, во всяком случае). Требование "использовать STLPort" — совершенно не катит. Вот и получается, что формально я могу использовать STL, но на практике — это очень сложно. Потому, как Microsoft в свое время поставил STL не в качестве рабочего инструмента, а лишь как отмазку и таким образом сильно затормозил весь C++ный прогресс.

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


AC>Ага, конечно. Что меня радует в студентах и некоторых людях недавно окончевших вуз, как в прочем и прочитавших книжку C++ за 24 часа, так это непонимание того, что С++ это язык незащищающий программиста от платформы. И
__любая__ ошибка программиста, пусть он будет хоть супер гигант от прогроаммировния, может привести к ситуации, в которой эту ошибку можно будет искать годами. В общем-то и писать на нем надо по другому чем на C#, Java, и т.д. А так, конечно, от языка ну ничего не зависит...

Старичек, у тебя эмоции явно бьют через край Относительно выделенного: ты прям так уверен что любая ошибка приведет к таким катастрофическим последствиям?


AC>Ну не надо, про тоже самое, что и MFC и другие STL — это часть языка, и от тебя вправе требовать его знание.

Так, че-то ты уходишь от темы. Я тебе пытаюсь объяснить, что те ошибки, о которых ты тут уже не первый топик открываешь связаны исключительно с твоими проблемами а не спроблемами библиотеки. Не знаю чем ты там лично пользовался и с чем сталкивался, но что касается существующих щас реализаций стл к примеру, то все их проблемы уже давн оизвестны и далеко не так многочисленны как ты пвтаешся нам тут преподнести.

AC>Ещё последнее время почему-то считается, что каждый должен знать и пользовать BOOST. Но несмотря на свою 'стандартность', эти библиотеки могут помочь для написания hello_world или студенту при изучении языка, в нормальном проекте от них вреда не меньше чем пользы

Это ты так считаешь. И насколько я помню ты именно с неверного толкования фразы о том что буст полезная вещь развел треп в разделе философии (ветка там про александреску и других). Для экономии времени можем уже сюда ничего не писать а просто ссылочку кинуть типа "пролдолжение здесь".

AC>>>Например опечатка в цикле по итератору вектора, где начало от одного контейнера, а конец от другого....
G>>Ага ОЧень интересно То есть делаем вывод что итераторы плохи?
AC>Нет делаем вывод, что миф о _надежности_ STL'я — это именно миф. Про удобство использования я вообще молчу. Какие еще у него плюсы, а какие плюсы у BOOST'а?

А че стл-я? Может делаем вывод, что миф о надежности оператора if это именно миф? Ну тыв блин даешь — хочешь шоб язык за тебя решал вопросы семантики программы?

AC>>>ИМХО, STL так же надежен (в рамках примеров из книжек), как и BOOST решает реальные проблемы (которые его авторы сами себе придумали).
G>>Слава богу что имхо.
AC>Дык тебе никто и не мешает огребстись граблей... потом, когда пройдет релиз... если тебя это конечно коснётся.

Ох блин Смешно слышать. Слава богу не один резил с стл-ем уже пройден. И с некоторыми вещами из буста кстати тоже. Так что не надо тока нас тут пугать

Ну вот давай по порядку. Назови мне косяки стл-я. Тока конкретные, а не так типа вот у нас тут меп упал — а почему упал — потмоу что мы им не так пользовались — вот уроды не могли за наспровреку воткнуть в стл.
Да, я согласен, что в той или иной реализации могут быть свои глюки и ошибки — сам с такими вещами сталкивался. Но могу тебе точно сказать, что ни один из них не был критичным. И вся та идея, которая у теюя идет уже тут почитай не первый раз о том что стандартные библиотеки — гауно — и надо писать свое, это просто бред. Ради интереса возми какой-нить компайлер без стл — например борланд с 3.1 (если не ошибаюсь — синие окошки такие а-ля турбо вижин ) и напиши на нем тот самый "реальный" прожект, которым ты тут в нос всем тычешь — типа не хело-ворлд. А заодно засеки скока цигеля потребуется на создания и вылизывания мапа, вектора, списков, стеков, очередей и семидесяти алгоритмов к ним. А потом еще приклюсуй к примеру либу для регулярных выращений, всякие там биндеры и тп. И никогда в своей гнилой житухе не поверю, что ты заприемлимое время все это сделаешь, и при тмо врамках идущего прожекта.
Так шо хватит пургу молоть. Все дело как грится в прокладке между сиденьем и рулем.

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

AJD>>А в чем MS виновата?

MS>Тем, что им надо было дорабатывать свой компилятор и приводить его в соответствии со стандартом C++.
Хм. Если ты про VC6, то это весьма старый компилятор, который, впринципе, не особо противоречил тогдашним стандартам.
Ну вот они и даработали и теперь у нас есть VC7.1

MS>После чего брать исходники STL и поставлять ничего не исправляя. Но они испортили STL (причем всяли весьма древнюю версию), понавставляли затычек, что-то пообкусали и т.д. Получилась кастрированная версия, в которой очень много граблей. Да хоть с теми же статическими переменными в std::map.
Дык они взяли готовую реализацию и ничего сами не писали.

MS>Реалии таковы, что народ до сих пор пользуется VC6, а иногда — даже VC5 и с этим приходится считаться (мне, во всяком случае). Требование "использовать STLPort" — совершенно не катит. Вот и получается, что формально я могу использовать STL, но на практике — это очень сложно. Потому, как Microsoft в свое время поставил STL не в качестве рабочего инструмента, а лишь как отмазку и таким образом сильно затормозил весь C++ный прогресс.

MS не может тормозить весь C++ный прогресс, так как они не утверждают стандарт и не только они делают компиляторы с++.

А может одной из причин успеха VC6 было как раз то, что MS упорно придерживается линии обратной совместмости своих продуктов( c VC5 достаточно безболезненно перейти на VC6, а потом на VC7.1)?

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

AC>Ну что ты, до перла — "продам маму и мозги" — мне далеко

Навеяло из Хумора:

Эйчары обязаны мотивировать сейлзов на приобретение коммуникейшн скиллз. В частности, презентейшн скиллз. Именно скиллз, а не нолледж, как считают некоторые, вообще часто определяют саксесс в бизнесе. И дело не только в профите. Своеобразным бенефитом от работы может быть и обычный сатисфекшн, которого нам всем так не хватает. Поэтому грамотный эйчар, проведя ассесмент и определив ниддингс будущих партисипантов, заказывает трейнинг.