Здравствуйте, 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 вообще к стандартной библиотеке степанова?