реал тайм осы

Первоначально опубликовано Olej Первоначально опубликовано evgen гм, гм и еще раз гм... темплейты замечательны тем, что ошибку в них не отследишь и не поймаешь в дебаггере, а что касается STL и его стандартности - читайте www.wxwindows.org, хотя проблемы портирования в случае выбора фиксированной платформы, видимо, не стоят. Только молиться надо, чтобы со следующей версией gcc ничего плохого с STL не произошло Об template & STL - если уж мы этот предмет зацепили (особенно потому, что он может иметь прямое касательство к аппаратному, embedded ПО): 1. template - самое большое расширение С++ с 1995г., может быть более существенное, чем наследование и множественное наследование... Это, наверное, самая массивная часть серьёзных публикаций последних 5-ти лет. Источники можно посмотреть здесь: http://qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=12&topic=943 http://qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=12&topic=1327 http://qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=12&topic=952 http://qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=12&topic=1002 Это настолько сильное расширение, что многие считают С++ с templates даже другим клоном языка. 2. template - как раз совершенно заманчивое средство больше для "аппаратног" ПО, потому, как бОльшая часть даже синтаксических проверок может быть выполнена препроцессорно, т.е. даже до начала компиляции.

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

Первоначально опубликовано Olej 3. STL, как естественное порождение template, не был стандартизован в стандарте 1998г. (не успели, т.к. первая HP-реализация STL была сделана в 1995г.), но уже тогда комитет по стандарьтзации рассматривал STL как стандарт post-factum... И в стардарте, не помню - 2000 или 2001г. - STL входит.

За стандартизацию STL вешать надо на той же ветке, что и за темплейты и эксепшены (точнее, за воспевание работы с эксепшенами как стандарный подход)

Первоначально опубликовано Olej 4. да это и не так важно - STL "внешняя" к языку часть - так ли принципиально, относить ли к стандарту FORTRAN библиотеки линейной алгебры. 5. но STL - и "не совсем" библиотека - это только щаблонные определения, т.е. библиотека, полностью определённая в *.h-файлах... без реализационной части. Любая из реализаций STL будет нормально использоваться если только компилятор строго поддерживает ISO стандарт в части templates. GCC 2.95 - поддерживает, в строгом соответствии со стандартами (говорят, что и более ранние версии тоже). Т.е. "молиться" - не стоит ;-) - от компилятора здесь ничего не зависит, только от реализации template...

Сейчас 2.9, как говорят, - уже не модно...народ переходит на 3.2 с чем-то там и переодически огребает проблемы.

Первоначально опубликовано Olej А почему им столько внимания... в этой теме?

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

Первоначально опубликовано Olej 1. STL реализации могут быть в 2-4 раза текстуально короче, и существенно устойчивее к ошибкам периода выполнения - то, что упоминалось в контексте надёжности ПО;

Если в одном месте убудет, то в другом - добавится.
Если в юзерской части реализация короче, то в части инклудов длиннее. И экзешник тоже раздувается. А как известно - чем больше программа[текст программы], тем больше в нем количество ошибок - это прямо относится к надежности.

Первоначально опубликовано Olej 2. STL реализации через какой-нибудь vector<X> или list<X>, как это не странно на первый взгляд, в конечном итоге (не отдельного оператора, а приложения в целом) могут оказываться ... существенно быстрее (1.4, 2 ... раза) относительно эквивалентов через рудиментные массивы X* ... Сам несколько раз проверял это в задачах цифровой обработки сигналов ... и каждый раз удивлялся ;-).

Чудес не бывает - процессор не может умножать и складывать числа быстрее чем он это делает.

Теперь по 2-й части нашего марлизонского балета...

Первоначально опубликовано evgen Если в юзерской части реализация короче, то в части инклудов длиннее. И экзешник тоже раздувается. А как известно - чем больше программа[текст программы], тем больше в нем количество ошибок - это прямо относится к надежности.

Точнее будет:
А как известно - чем больше исходный текст программы, тем больше в нем количество ошибок - это прямо относится к надежности.
Вот и я об том же... что текст в 4 раза короче - будет иметь в 4 раза (в худшем случае) частоту ошибок периода выполнения (очень важно! - не нужно мне долдонить про ошибки компиляции).

Первоначально опубликовано evgen Чудес не бывает - процессор не может умножать и складывать числа быстрее чем он это делает.

Чудеса тоже бывают... но, как учит закон термодинамики, 2-й, кажется - о-о-о-чень редко ;-).

Но ускорение STL-реализаций происходит без вмешательства чудес. На то есть много (и даже очень много, чтоб все их перечислять в форуме) оснований. Многие их них отлично обсуждаются в переводе: Мейерс С. Эффективное использование STL. Библиотека программиста. - СПб.: Питер, 2002. Но есть и другие, связанные с особенностью задач обработки данных и управления:

- обработка данных (блочных данных) часто делается циклических применением операций к данным. Традиционное решение: в цикле for применяеися функция обработки, которая в точку обработки передаётся своим указателем. STL решение: применение циклических алгоритмов STL, которым передаётся не указатель функции, а функтор (анонимный объект класса, в котором определена операция "()"). Так вот - второе решение практически всегда быстрее (от незначительных 40% до 3-7 раз, я проверял эти цифры!) за счёт того, что в этом случае компилятор имеет информацию и может значительно оптимизировать код.

- а это уже совсем не так очевидно: очень часто в потоковой обработке экспериментальных данных (в той же цифровой обработке сигналов, но не только) - над потоком данных производится, часто не в один проход, некоторая предварительная "чистка", когда некоторые фрагменты потока должны быть квалифицированы как "запорченные" и выброшены... В традиционном решении у вас есть на выбор:
а).уплотнять данные, перемещая большие объёмы на место устраняемых б).отмечать устраняемые данные "флагом"... а потом при многократных циклах обработки этот флаг - обходить. В STL решении, например list<X> - у вас нет этих проблем! И итоговый выигрыш с лихвой перекрывает потери на элементарных операциях, связанных с доступом к более сложной структуре. Проверено - на нескольких реальных задачах, имеющих практическую ценность - до 2-2.5 раз.

Первоначально опубликовано Olej Теперь по 2-й части нашего марлизонского балета... Первоначально опубликовано evgen Если в юзерской части реализация короче, то в части инклудов длиннее. И экзешник тоже раздувается. А как известно - чем больше программа[текст программы], тем больше в нем количество ошибок - это прямо относится к надежности. Точнее будет: А как известно - чем больше исходный текст программы, тем больше в нем количество ошибок - это прямо относится к надежности. Вот и я об том же... что текст в 4 раза короче - будет иметь в 4 раза (в худшем случае) частоту ошибок периода выполнения (очень важно! - не нужно мне долдонить про ошибки компиляции). Первоначально опубликовано Olej А что - у STL нет исходного кода ? или он непогрешим и сразу был дан в одной единственно верной версии ? И платформенных зависимостей в нем нет ? (вот это уже не помню) Первоначально опубликовано evgen Чудес не бывает - процессор не может умножать и складывать числа быстрее чем он это делает. Чудеса тоже бывают... но, как учит закон термодинамики, 2-й, кажется - о-о-о-чень редко ;-). Но ускорение STL-реализаций происходит без вмешательства чудес. На то есть много (и даже очень много, чтоб все их перечислять в форуме) оснований. Многие их них отлично обсуждаются в переводе: Мейерс С. Эффективное использование STL. Библиотека программиста. - СПб.: Питер, 2002. Но есть и другие, связанные с особенностью задач обработки данных и управления: - обработка данных (блочных данных) часто делается циклических применением операций к данным. Традиционное решение: в цикле for применяеися функция обработки, которая в точку обработки передаётся своим указателем. STL решение: применение циклических алгоритмов STL, которым передаётся не указатель функции, а функтор (анонимный объект класса, в котором определена операция "()"). Так вот - второе решение практически всегда быстрее (от незначительных 40% до 3-7 раз, я проверял эти цифры!) за счёт того, что в этом случае компилятор имеет информацию и может значительно оптимизировать код.

Бред какой-то. Может таки у вас в кАнсерватории что-нибудь не так ?
При любой разумной организации программы накладные расходы на вызов функций составляет доли процента от всего объема, использование inline (явное или неявное ) еще больше уменьшает. Использование STL в данном случае эквивалентно switch'у c кучей циклов for, в каждом из которых вызывается своя функция обработки. Вы скажете - вариант с STL - короче, а я скажу - что менее надежен и недоступен для отладчика.

Первоначально опубликовано Olej - а это уже совсем не так очевидно: очень часто в потоковой обработке экспериментальных данных (в той же цифровой обработке сигналов, но не только) - над потоком данных производится, часто не в один проход, некоторая предварительная "чистка", когда некоторые фрагменты потока должны быть квалифицированы как "запорченные" и выброшены... В традиционном решении у вас есть на выбор: а).уплотнять данные, перемещая большие объёмы на место устраняемых б).отмечать устраняемые данные "флагом"... а потом при многократных циклах обработки этот флаг - обходить. В STL решении, например list<X> - у вас нет этих проблем! И итоговый выигрыш с лихвой перекрывает потери на элементарных операциях, связанных с доступом к более сложной структуре. Проверено - на нескольких реальных задачах, имеющих практическую ценность - до 2-2.5 раз.

Вы делаете мне смешно. добавьте в традиционное решение "в) использовать структуру данных "список"" и уже тогда сравнивайте его производительнось с вариантом на STL и уже тогда делайте выводы.
Сравнивать быстродействие можно только для эквивалентных алгоритмов - что для STA специалиста должно быть так же ясно, как для физиков/конструторов знание о том, что киллограммы можно сравнивать только с километрами, но никак не секундами.

Первоначально опубликовано evgen Бред какой-то. Может таки у вас в кАнсерватории что-нибудь не так ? .... ....

Ничего не могу сказать про кансерватории...
Но я вам пересказал (собственно - не вам, вам оно не надо, может кому пригодится...) - достаточно очевидные и известные вещи: сначала я на это напоролся сам, а потом видел у Мэйерса и в ссылках на него...
Т.е.: берём указанный букварь в руки - и читаем... Там всё очень доходчиво, по 3 раза повторено...

Первоначально опубликовано evgen Вы делаете мне смешно. добавьте в традиционное решение "в) использовать структуру данных "список"" и уже тогда сравнивайте его производительнось с вариантом на STL и уже тогда делайте выводы.

Я не делаю вам смешно - мне как-то делать вам смешно ... до фени...
А вот то, что вы пишете - я вот это когда-то и делал, до поры до времени. Только то, что вы пишете - это и есть "ручная" реализация STL буква в букву, с той лишь разницей, что на 1 строку приложения STL-реализации - приходится 20-25 строк "ручной реализации" (о чём говорилось выше)... А по сути - это абсолютно одно и то же, поэтому именно эту реализацию я и не сравнивал. "Масло маслянное". С той ещё разницей, что в "ручной" реализации вы ещё наделаете своих ошибок кучу, а эффективность её будет существенно хуже...

Первоначально опубликовано Olej Первоначально опубликовано evgen Бред какой-то. Может таки у вас в кАнсерватории что-нибудь не так ? .... .... Я не делаю вам смешно - мне как-то делать вам смешно ... до фени... А вот то, что вы пишете - я вот это когда-то и делал, до поры до времени. Только то, что вы пишете - это и есть "ручная" реализация STL буква в букву, с той лишь разницей, что на 1 строку приложения STL-реализации - приходится 20-25 строк "ручной реализации" (о чём говорилось выше)... А по сути - это абсолютно одно и то же, поэтому именно эту реализацию я и не сравнивал. "Масло маслянное". С той ещё разницей, что в "ручной" реализации вы ещё наделаете своих ошибок кучу, а эффективность её будет существенно хуже...

Ктож вам доктор, если вы в 25 строках делаете кучу ошибок - то вам тогда вообще программированием заниматься противопоказано. При большом умении можно в и одной строке STL-реализации наделать кучу ошибок. И потом долго и упорно искать где она происходит.