"NoFate" <22574@users.rsdn.ru> wrote in message
news:1697456@news.rsdn.ru...
From: NoFate nofatya.livejournal.com

Сегодня узнал о том, что один преподаватель МГТУ им. Баумана имеет к STL
достаточно негативное отношение. Мотивирует тем, что иногда программы с
использованием STL ведут себя странно на больших объемах данных. Он приводил
пример из жизни: студент выполнил курсовую, связанную с работой с БД на
"живом" языке (или как оно называется) и при подключении больших словарей
время работы стало экспоненциальным, хотя должно было быть линейным, что и
наблюдалось на малых словарях. Так вот, потом для интереса переписали без
STL, но с теми же алгоритмами — всё заработало.

Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от
преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как
оно возможно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
STL (мнение преподавателя) Оценить


По симптомам можно преположить, что в какой то момент у системы кончается
оперативная память и начинает работать файл подкачки.
Во-вторых ничего не говорится о том насколько грамотным, и рациональным было
использоывание STL в данном приложении. В-третьих кто проверял, что студент
подсунул не отладочный вариант приложения?

А вообще любопытно было бы узнать, о преподавателе какой дисциплины идет
речь? Не "охрана труда" случайно?

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

R>А вообще любопытно было бы узнать, о преподавателе какой дисциплины идет
R>речь? Не "охрана труда" случайно?

Базы данных, если не ошибаюсь

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

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

R>>А вообще любопытно было бы узнать, о преподавателе какой дисциплины идет
R>>речь? Не "охрана труда" случайно?

NF>Базы данных, если не ошибаюсь

Для этого есть СУБД, зачем еще stl там нужен?

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


NF>>Базы данных, если не ошибаюсь
А>Для этого есть СУБД, зачем еще stl там нужен?

Всё написано в корневом сообщении...

"Павел Кузнецов" <5834@users.rsdn.ru> wrote in message news:1697678@news.rsdn.ru...
>


теперь нормально?

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

DP>А теперь конкретней что, как, сколько ???

Значит ни чего конкретного ... просто захотелось мягко говоря по..говорить ...
У меня за много лет использования STL подобных проблем не было ...
но если все таки будет конкретный пример кода то я думаю можно будет сказать в чем проблема

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

NF>Сегодня узнал о том, что один преподаватель МГТУ им. Баумана имеет к STL достаточно негативное отношение. Мотивирует тем, что иногда программы с использованием STL ведут себя странно на больших объемах данных. Он приводил пример из жизни: студент выполнил курсовую, связанную с работой с БД на "живом" языке (или как оно называется) и при подключении больших словарей время работы стало экспоненциальным, хотя должно было быть линейным, что и наблюдалось на малых словарях. Так вот, потом для интереса переписали без STL, но с теми же алгоритмами — всё заработало.

NF>Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как оно возможно?



ИМХО Им просто обидно, что они в своё время писали всё это руками. Они не могут смириться, что сейчас программист может просто заюзать библиотечный класс. За такими дешёвыми наездами на стандартную библиотеку — толи желание самому подняться, толи не знаю ещё что. В общем — не уважение преподу. Единственная поблажка ему может быть сделана за старость.
Тяжёлое детство — велосипедный спорт
Надеюсь никто из доверчивых студентов не повёлся на такие тупые разводы.

Более печально, что и среди профессиональных программистов, которые начинали писать ещё лет 10 назад тоже такие встречаются...

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


DP>Значит ни чего конкретного ... просто захотелось мягко говоря по..говорить ...
DP>У меня за много лет использования STL подобных проблем не было ...
DP>но если все таки будет конкретный пример кода то я думаю можно будет сказать в чем проблема

Не могу сказать, что за много лет, но таких проблем не возникало и у меня. Примера действительно нет =) Не давал...

ребята написали свои алгоритмы, вместо того, чтобы научится использовать существующие

Здравствуйте, NoFate, Вы писали:
NF>Т. е. написанное ручками эффективнее, чем STL-кие реализации? Субъективное мнение — это маловероятно.
Для конкретной задачи ты скорее всего сможешь написать более эффективный контейнер

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

NF>Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как оно возможно?

бывает. из опыта: чаще всего это происходит с операциями new-delete.
то с чем сталкивался на MS visualC++:
1) вина программиста
map — большое число маленьких объектов. заполнение быстое, удаление всех (т.е. clear()) при 10000 объектах — задумывалась на несколько секунд. помог boost с его аллокаторами. Этот случай нельзя отнести к серьезным недостаткам реализации т.к. new-delete не оптимизированы для малых объектов и это нужно помнить.
2) вина реализации
deque. около 10000000 (или около того) push-back'ов затем полное удаление. в VC2003 проходит без проблем в VC2005 не дождался окончания (не помню точно на удалении или вставке). вектор летает.
---
Вывод:
1) сама по себе stl не может быть тормозной т.к. это только спецификация интерфейса библиотеки и некоторых особенностей ее работы
2) иногда проблемы с реализацией stl иногда с использованием. Лучше всего использовать одну реализацию (например stlport) поведение которой изучено чтобы не получать непронятное поведение при смене версии компилятора
3) действительно иногда самописный вариант работает быстрее, но сначала нужно изучить все, что предоставляет stl и особенности использования, и если стало очевидно, что выше скорости не добится, стоит подумать о велосипеде

В старой версии g++ кажется 2.95 в алгоритме sort была ошибка, которая проявлялась как раз на больших данных. Пришлось sort заменить на stable_sort.

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

NF>Сегодня узнал о том, что один преподаватель МГТУ им. Баумана имеет к STL достаточно негативное отношение. Мотивирует тем, что иногда программы с использованием STL ведут себя странно на больших объемах данных. Он приводил пример из жизни: студент выполнил курсовую, связанную с работой с БД на "живом" языке (или как оно называется) и при подключении больших словарей время работы стало экспоненциальным, хотя должно было быть линейным, что и наблюдалось на малых словарях. Так вот, потом для интереса переписали без STL, но с теми же алгоритмами — всё заработало.

NF>Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как оно возможно?

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

1) Все зависит от платформы, например, в последних библиотеках Линуксячьих граммотный маллок с кешем малых объектов. STLport тоже имеет аналогичный кеш
2) Еще раз соглашусь. См. мой пост выше. Баги в реализациях STL бывают.

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

NF>>Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как оно возможно?

WA>бывает. из опыта: чаще всего это происходит с операциями new-delete.
WA>то с чем сталкивался на MS visualC++:
WA>1) вина программиста
WA>map — большое число маленьких объектов. заполнение быстое, удаление всех (т.е. clear()) при 10000 объектах — задумывалась на несколько секунд. помог boost с его аллокаторами. Этот случай нельзя отнести к серьезным недостаткам реализации т.к. new-delete не оптимизированы для малых объектов и это нужно помнить.
WA>2) вина реализации

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

A>пример 2
A>int_v.reserve(10000);
A>for(int = i; i < 10000; ++i)
A> int_v.push_back(i);

A>такшто использовиние библиотеки не освобождает от
A>использовоная головы

Так это и есть "странное" поведение. Лектор прав.

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

B>Абсолютно так же можно утверждать,
B>что программы на С++ на больших объемах ведут себя странно и тормозят.
B>А что?
B>Программа была написана на С++? Да!
B>Тормозила? Еще как!
B>Вывод — С++ тормозной язык.

Перепиши программу на Perl.

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

NF>Сегодня узнал о том, что один преподаватель МГТУ им. Баумана имеет к STL достаточно негативное отношение.

вот ещё один случай: http://www.rsdn.ru/Forum/?mid=1189102

Автор: McSeem2
Дата: 25.05.05

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

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

av>>Можно узнать, о каком именно преподавателе идет речь?
NF>М-м-м =) Марков. ИУ-9

av>>Я бы посоветовал не очень верить преподавателям нашего славного университета... за 6 курсов я видел только двух преподавателей (имеются в виду спецдисциплины), которые более-менее разбирались в преподаваемом предмете.
NF>Да, для нашего славного ВУЗа это характерно...

Характерно не только для вашего ВУЗа. У нас не лучше, за все предметы не ручаюсь, говорю именно о тех, что касаются программирования. Преподаватели на нашей кафедре повергают меня в тоску и уныние. Бесполезно, что-то спрашивать и боже упаси сказать, что я программист, могут потом все нервы вытрясти. Докапываться до ерунды.

Я думаю преподаватель с негативным отношением к STL, просто её плохо знает и никогда не участвовал в разработке больших проектов.

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

NF>Сегодня узнал о том, что один преподаватель МГТУ им. Баумана имеет к STL достаточно негативное отношение. Мотивирует тем, что иногда программы с использованием STL ведут себя странно на больших объемах данных. Он приводил пример из жизни: студент выполнил курсовую, связанную с работой с БД на "живом" языке (или как оно называется) и при подключении больших словарей время работы стало экспоненциальным, хотя должно было быть линейным, что и наблюдалось на малых словарях. Так вот, потом для интереса переписали без STL, но с теми же алгоритмами — всё заработало.

NF>Я, в общем-то, не очень верю подобным рассказам пусть даже идут они от преподавателей, но всё таки интересно мнение. Возможно ли подобное? И как оно возможно?

Может просто он скомпилировал в Debug?
У меня такое было — STL vector в VisualC++ 6.0 в Debug Mode был медленнее самого себя в
Release Mode в ДЕСЯТКИ раз. Из-за того что очень много вызовов функций,
которые в Release разворачиваются в inline.