AC>Был мап с элементами, и список по которому они удалялись. По логике в список один элемент попадать два раза не должен был, но таки попал... в совершенно непредсказуемой ситуации, которая никогда не должна была случится. Почему для мапа не сделали проверку на удаление end, для меня загадка.
Дык я че-то не понял — кто виноват-то? СТЛ или программер, который не поставил проверки на дубликаты ключей и на наличие/отсутсвие элемента в мапе?
AC>Была реальная ситуация с мапом, который рухнул на боевом серваки после мелкого фикса, причем бага невоспроизводима в тепличных условиях. Ловили по корке.
G>>> Я это себе поставлю в origin. AC>>А в чем поинт? G> В эффекте, производимом на неподготовленного слушателя!
Ну что ты, до перла — "продам маму и мозги" — мне далеко
Здравствуйте, 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 решает реальные проблемы (которые его авторы сами себе придумали).
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>Слава богу что имхо.
Дык тебе никто и не мешает огребстись граблей... потом, когда пройдет релиз... если тебя это конечно коснётся.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был.
Ты что, не читал, как он рыбой отравился, в результате чего в горячечном бреду родилась STL?
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>А мне чего-то кажется, что несмотря на ФИО Алек Степанов ни фига не русский и никогда им не был. R>Ты что, не читал, как он рыбой отравился, в результате чего в горячечном бреду родилась STL?
R>http://www.rsdn.ru/Forum/?mid=16763
Здравствуйте, AndrewJD, Вы писали:
MS>>Как время летит! STLю уже 25 лет, но усилиями Microsoft она до сих пор крива.
AJD>А в чем MS виновата?
Тем, что им надо было дорабатывать свой компилятор и приводить его в соответствии со стандартом C++. После чего брать исходники STL и поставлять ничего не исправляя. Но они испортили STL (причем всяли весьма древнюю версию), понавставляли затычек, что-то пообкусали и т.д. Получилась кастрированная версия, в которой очень много граблей. Да хоть с теми же статическими переменными в std::map. Реалии таковы, что народ до сих пор пользуется VC6, а иногда — даже VC5 и с этим приходится считаться (мне, во всяком случае). Требование "использовать STLPort" — совершенно не катит. Вот и получается, что формально я могу использовать STL, но на практике — это очень сложно. Потому, как Microsoft в свое время поставил STL не в качестве рабочего инструмента, а лишь как отмазку и таким образом сильно затормозил весь C++ный прогресс.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
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)?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Alexey Chen, Вы писали:
AC>Ну что ты, до перла — "продам маму и мозги" — мне далеко
Навеяло из Хумора:
Эйчары обязаны мотивировать сейлзов на приобретение коммуникейшн скиллз. В частности, презентейшн скиллз. Именно скиллз, а не нолледж, как считают некоторые, вообще часто определяют саксесс в бизнесе. И дело не только в профите. Своеобразным бенефитом от работы может быть и обычный сатисфекшн, которого нам всем так не хватает. Поэтому грамотный эйчар, проведя ассесмент и определив ниддингс будущих партисипантов, заказывает трейнинг.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.