Вот и ты возьми - из реальных разработчиков и посади их за унивскую задачу. Боюсь, что ужасаться результатам не придется.
увы, таки придется:-)
ибо нужны знания из других областей. Например, физика.
Взять ту же кафедру *Компьютерной графики*. Без знаний в области оптики делать там нечего:-)

Похоже, совсем запутал. Эти два разных человека работают в разных коллективах, над разными продуктами и не знакомы друг с другом. С первым я работал раньше в Киеве, со вторым работаю сейчас в Берлине. Все описанные проблемы относятся к текущему проекту.
Место есть лишь для одного компа и лишь в нестандартных малых корпусах (минимум плат расширения). Помимо компа есть две отслеживающие системы (оптическая и электромагнитная) и еще кое-какая электроника. Все это в компактном мобильном корпусе, таком чтобы операционная сестра могла отодвинуть его в сторону, когда нужно место для другого оборудования. Решение с терминалом не проходит по многим причинам, но мы его пытаемся протолкнуть. С отрисовкой на экране посложнее будет. Данные (а это томограммы, атласы и т.д.) занимают сотни мегабайт. С такими объемами даже GeForce 7800GTS с трудом справляется.

Именно эти проблемы и возникают (за исключением неудобного кода). Но не из-за неправильного применения STL. Просто STL слишком абстрактен, чтобы быть эффективным. В некоторых случаях у нас возможна эффективная линейная сортировка, противопоставить чему STL-библиотеке нечего. И так далее. Практически всюду в критических ко времени выполнения кусках кода "С с классами" и ассемблером дают серьезный выигрыш по сравнению с С++/STL/CGAL. Кроме того, у нас есть проблема фрагментации адресного пространства и, как следствие, невозможность получить новый блок памяти, даже если есть необходимое количество свободной оперативной памяти. За это отдельное спасибо С++ с его бедной подсистемой управления памятью и С++ ассам, динамически создающим тысячи объектов.

При написании конкретных программ ограниченность вычислительных ресурсов всегда является неявным условием решаемой задачи. Если это условие игнорируется, то я не считаю задачу решенной.

Странные у тебя все же представления об инженерах - ни физики не знаю, ни, наверное, метематики...
Хотя, может сейчас так и везде готовят. Что до меня - то физмат мне весьма и весьма помогает. И именно в силу того, что дали связанное понимание математики, физики и возможности проецировния теории на прикладные области.

почему же?
об инженерах я понятие имею, т.к. это мое первое образование :-)
Но мы о программистах. Это раньше информатике учили на факультетах Математики (приматы), Машиностроения, ... . Сейчас же это отдельный факультет. И поиметь такое *счастье*, как получить в нагрузку к информатике еще и физику, химию,... уже врядли кто может:-)
Тут ты можешь себе выбрать к Информатике еще и Nebenfach. Но многие и не подумают делать себе такую каку под названием *физика* 8-)
Я вот хотел взять Japanologie 8-), так университетские крысы отказали. Пришлось брать Математику.
Так что, огромный процент программеров в Германии (и думаю вне ее) имеют по физике почти нулевые знания :-Р

Если это условие игнорируется, то я не считаю задачу решенной.
-----
Увы, в системах есть характеристика - время реакции системы - т.е. время с момента получения запроса до момента выдачи результата. До тех пор, пока время реакции гарантируется разработчиком - задача всегда решена, независимо от того каким образом это сделано.
Просто STL слишком абстрактен, чтобы быть эффективным.
-----
Хммм... с каких это пор абстрактность стала синнонимом неэффективности? Возьми, к примеру, математику - совершенно абстрактная вещь - и попробуй обойтись без нее в разработке...
Практически всюду в критических ко времени выполнения кусках кода "С с классами" и ассемблером дают серьезный выигрыш по сравнению с С++/STL/CGAL
-----
Если вы найдете время, чтобы еще раз "сесть и обдумаеть" задачу, желательно - с нуля, совершенно оторвавшись от существующего решения, то выяснится весьма интересная штука - те самые "критические по времени выполнения куски С++ с ассемблером" могут вообще исчезнуть как таковые, а остаток приемлемо решится штатными средствами С++/С#/Java & etc., бо, нет недостаточной эффективности языков, а есть - непонимание задачи и неумение применять имеющиеся средства.
у нас есть проблема фрагментации адресного пространства
-----
Ну-ну... бедняги, 65К дескрипторов сегментов в потоке не хватает... можно подумать, что new/delete автоматическти привязывающие vtable к области данных создают больше проблем, чем alloc/free с последующим ручным назначением так же в ручную сформированных эмуляторов той же vtable и всеми последующими глюками связанными с сопровождением... К тому же время, съедаемое построением и сопровождением данных сурогатов, не позволяет взять документацию по современным процам и подсистеме управления памятью в виндах и научиться их эффективно использовать... даже через тот же STL.

Попытаюсь объяснить без намеков. Если то, что Вы говорите верно
то Ваш коллега не в состоянии эффективно решить ни одной современной задачи. Жаль, что Вы не заметили, что программирование превратилось в производство и выжить в нем могут либо гении-одиночки, либо коллективы.

почти нулевые знания :-Р
-----
Возможно. Но система, выдающая в качестве результата нечто, не имеющее знаний в тер.областях и, соответственно, навыков использования тер.знаний на практике, а имеющих только весьма специальные знания в отдельной области - это не уни, это даже не политех, а всего лишь - профтех. Те самые советские СПТУ, дававшие "рабочую" специальность. В этих СПТУ была даже соответствующая квалификация - техник-кодировщик.

Похоже, эту ссылку http://infobub.arbeitsagentur.de/kurs/index.html Вам уже не дождаться. Там можно поискать в городе и окрестностях, но лучше к Beraterу сходить, поулыбаешься, попросишь, чего-нибудь найдет.
Про качество не могу сказать, у нас в Саксонии по администрации не очень были, но для языка пользительно.
Удачи.

P.S. Квалификация техник-кодировщик все же предполагала знание математики, физики и химии в объеме тогдашней средней школы.

Попытаюсь объяснить без намеков.
-----
Вообще-то - бесполезно. Специфика с(т)раны...
Sorry.

Причем здесь время реакции системы?

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

Гол в свои ворота. Критические ко времени выполнения куски в нашем случае - обработка изображений и других собираемых данных, визуализация - соль проекта и выкинуть не получится. А настаивание на использовании ООП/ООА/C++ вопреки всем возникающим сопутствующим проблемам как раз и выявляет непонимание задачи и неумение применять имеющиеся средства. Java и C# некоторые тоже пытались протолкнуть, но быстро успокоились после пары провальных экспериментов.

Причем здесь дискрипторы сегментов и vtable? Если необходимо динамически наращивать массив данных (нет возможности получить приемлемую верхнюю оценку), то применение пары new/delete приводит к резервированию нового блока памяти, переписыванию содержимого, освобождению старого блока. Адресное пространство процесса при этом фрагментируется. Например, если первоначально был зарезервирован блок памяти размером 1GB, затем понадобилось увеличить этот блок до 1.5GB и были использованы new/delete, то в системе будет 1GB свободного адресного пространства, за ним 1.5GB занятого и опять 1.5GB свободного. Последующая попытка увеличить размер зарезервированного блока до 2GB не пройдет, хотя физической памяти может быть достаточно (речь о 32битной системе). Данную проблему можно решить "уплотнением" памяти - блок должен быть сдвинут в начало памяти. Но new/delete здесь ничем не помогут. Помимо alloc/free есть еще и функция realloc, при использовании которой в описанной выше ситуации проблема фрагментации адресного пространства просто не возникает. Плюс не происходит ненужное переписывание данных как при использовании new/delete.

Причем здесь время реакции системы?
-----
Ну вы же должны показать картинку тому кто смотрит. Мгновенно вы этого сделать не можете. Значит есть время в течении которого произойдет обработка информации и выдача изображения. Само время, для оценки - "задача решена", роли не играет, важно, чтобы система в него гарантированно укладывалась.
В нашем частном случае возможна более эффективная реализация сортировки, чем предлагаемая слишком общими методами из STL.
-----
В вашем "частном случае" необходимо на тех же принципах, на которых построена STL, написать шаблон, реализующий требуемую сортировку, с сохранением традиционных методов STS и использовать именно его для решения задач. Но никак не переходить на "простой Си".
Гол в свои ворота.
-----
Увы, но нет. Не существует задачи, для которой ООП-язык менее приспособлен, чем процедурный. Конкретный тип самого языка - вообще никакой роли не играет.
Единственное, в чем проигрывает ООП-язык - в нем есть небольшой оверхед при вызове виртуальных функций, но он явно не критичен.
Адресное пространство процесса при этом фрагментируется.
-----
Угу... стоит последовать совету - изучить соответствующую документацию. Тогда не будет проблем с фрагментацией.
Данную проблему можно решить "уплотнением"
-----
Еще раз - можно и не улотнять. Читайте документацию.
Годиках этак в 80-х одному мужичку было предложено модифицировать код, который строил в памяти сложную многоразмерную матрицу по исходным данным, потом обсчитывал ее по не слишком сложному алгоритму. Программа, в принципе, была написана, но для работы требовалось иметь "большую" ЕС с 16-ю мегами памяти. От мужичка же требовалось портировать программу на одну из малых машин с 16 килобайтами памяти. Разумеется, вся матрица не вмещалась в память и народ ожидал тех же мучений, которые описываете вы - фрагментация, выгрузка-загрузка сегментов, кеширование/декеширование и т.п... А мужичек чуть ли не на другой день сдал работающую программу. И она делала именно то, что требовалось и за то время, которое отводилось.

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

Если необходимо динамически наращивать массив данных (нет возможности получить приемлемую верхнюю оценку), то применение пары new/delete приводит к резервированию нового блока памяти, переписыванию содержимого, освобождению старого блока. Адресное пространство процесса при этом фрагментируется. Например, если первоначально был зарезервирован блок памяти размером 1GB, затем понадобилось увеличить этот блок до 1.5GB и были использованы new/delete, то в системе будет 1GB свободного адресного пространства, за ним 1.5GB занятого и опять 1.5GB свободного. Последующая попытка увеличить размер зарезервированного блока до 2GB не пройдет, хотя физической памяти может быть достаточно (речь о 32битной системе).
Ваши программисты никогда не слышали о std::deque?
Кроме того, у нас есть проблема фрагментации адресного пространства и, как следствие, невозможность получить новый блок памяти, даже если есть необходимое количество свободной оперативной памяти. За это отдельное спасибо С++ с его бедной подсистемой управления памятью и С++ ассам, динамически создающим тысячи объектов.
Мда... Может вс╦ таки лучше программистов знающих С++ нанять? В любой приличной документации/книге по STL говорится, что стандартный аллокатор неэффективно работает с большим количеством маленьких объектов, лечится это элементарно - написанием собственного аллокатора! Примеры - в любой хорошей книге по C++.
В нашем частном случае возможна более эффективная реализация сортировки, чем предлагаемая слишком общими методами из STL. Они не могут учитывать специфику наших данных.
Это лечится написанием одной! функции-шаблона реализируюшей данный алгоритм сортировки, и дальнейшим использованием данной функции со всеми типами ваших контейнеров.
Гол в свои ворота. Критические ко времени выполнения куски в нашем случае - обработка изображений и других собираемых данных, визуализация - соль проекта и выкинуть не получится.
Гол в Ваши ворота. При правильном написании такие библиотеки зачастую быстрее работают на С++, так как компайлер может проинлайнить разные функторы, что невозможно на С.

Подскажите в Нюрнберге и в окрестностях хорошие программисткие курсы, которые оплачивает арбайтсамт.
Я имею ввиду фундаметальные курсы по джаве, с++ или по сапу.
Не бывает ни хороших, ни фундаментальных курсов по программированию. Если не получается учится самой, присмотрись лучше к заочным Uni или FH. http://www.studieren.de/listbox4.asp
Например бакалавр по информатике в Хагене или Медиенинформатик в Берлине или Бранденбурге.

Единственное, в чем проигрывает ООП-язык - в нем есть небольшой оверхед при вызове виртуальных функций, но он явно не критичен.
А иногда он выигрывает. Например сортировка в STL может работать быстрее чем qsort в C, так как functor реализующий сравнение объектов в С++ инлайнится, а в С та же функция вызывается через указатель.

Возможно. Но система, выдающая в качестве результата нечто, не имеющее знаний в тер.областях и, соответственно, навыков использования тер.знаний на практике, а имеющих только весьма специальные знания в отдельной области - это не уни, это даже не политех, а всего лишь - профтех. Те самые советские СПТУ, дававшие "рабочую" специальность. В этих СПТУ была даже соответствующая квалификация - техник-кодировщик.
Этому в Германии соответствует Ausbildung zum Fachinformatiker-Anwendungsentwickler. ВУЗы всё таки теоретичесике основы дают. Конечно дают не все одинаково хорошо, может Томассону в этом плане не повезло.

Задайся другим вопросом - почему официально считается, что работу ядра *nix'а понимают всего человек 10-12 в мире.
Это такой же миф, как и заявление, что ОТО понимают единицы.

Решать большинство задач оптимальным для нашего комплекса методом - единственный выход, а все стандартные библиотеки (уж тем более реализованные в виде шаблонов как CGAL) просто абсолютно не пригодны.
То есть Вы в принципе отрицаете пригодность OOP-языков для Вашей задачи?

Я же сказал, что "если игнорируется ограниченность вычислительных ресурсов..." Как можно при этом что-то гарантировать относительно времени реакции системы?

Кому это необходимо? Языку С++? У нас море шаблонов в проекте, но практически все они используются лишь единожды и часто некоторые операции имеют смысл лишь для весьма определенного параметра шаблона. Да возьмите тот же STL c его шаблонами-контейнерами. Для некоторых из них задана операция сортировки (std::list<>::sort()), но упорядоченность имеет смысл не всегда. Если для объектов класса Object задать операции сравнения невозможно (и не нужно), то можно ли использовать контейнер std::list<Object>? Создавать свой шаблон list, каким-то образом ограничивать использование std::list<Object>? Или такой пример: операция нормализации для шаблона Vector3D<> имеет смысл? А для Vector3D<int>? Конечно проблемы решаемы, но получается программирование для С++, а не использование С++ для реализации решения конкретной задачи.

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

Вы просто не поняли в чем состоит проблема фрагментации адресного пространства. Все советы прочитать документацию, упоминания таблицы виртуальных функций и дискрипторов сегментов совершенно не в тему. И у меня лично проблема не возникает - я использую realloc.