Народ!
Подскажите в Нюрнберге и в окрестностях хорошие программисткие курсы, которые оплачивает арбайтсамт.
Я имею ввиду фундаметальные курсы по джаве, с++ или по сапу.

Курсы фундаментальными не бывают...
Фундаментальным бывает высшее образование.

В Нюрнберге не знаю, да и вообще где нормально учат тоже... Я учился в институте Тайлорикс. У них филиалов по Германии много. Но там не учат, а книжки дают, комп дают, и препод один на неделю на группу из 6-10 человек. Люди приходяи и уходят. У каждого индивидуальный курс. Есть вопросы - задаёш преподу. Раз в две неделю прюфунг по предмету. У меня было 6 предметов. Я их и так знал. Ходил просиживать штаны, но потом дали диплом.
А вообще курсы, которые ты хочешь существуют. Может кто и подскажет.

за те 5 лет, что чел проводит в попытках получить высшее образование, можно и дома заложить фундамент 8-)

по SAPу, скорее всего, арбайтсамт дулю скрутит:-)
Слишком дорого им будет.
Вам по языкам для себя или для бумажки надо?
Если для себя, то книга - лучший курс:-)

В стиле вашего ответа. Является ли значение True RMS сигнала его значением (оценкой) усредненной ╨нергиии?

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

Книги я читаю, но без реальных заданий, забываю все через месяц.
так программируйте:-). Читайте следующие книги, которые описывают решения в областях, где у вас нет опыта.
А то с таким подходом после курсов опять все забудете через месяц:-)
Программист - это как музыкант. Либо каждый день по несколько часов, либо нечего и браться:-). Это если есть желание стать профессиональным программистом, а не переодически пару скриптов для своего сайта/приложения написать.
Вот примерный список того, что необходимо для фундамента:
-- синтаксис какого-то языка (С++, Java, С#, ...)
-- алгоритмы
-- структуры данных
-- алгоритмы из той области, в которой программируете (графика, сети, ...)
Как видите, тем не так уж и много:-). По каждой из них вам надо будет прочитать (а главное, понять) 2-3 книги.
Освоив их, вы заткн╦те за пояс очень многих программеров с высшим образованием:-)
Потом уже пойдут темы, которые упрощают сам процесс программирования и повышают его качество:
-- patterns
-- проектирование
-- testing
-- ...
Если встанет вопрос бумажки, то всегда можно сдать экзамены на сертификаты (например, MCAD). С ними можно найти работу и без диплома ВУЗа.

Если вам нужна бумажка, делаете правильно - тратить свои кровные на формальность глупо. Под формальностью я понимаю требование работодателя доказать квалификацию через CV. Разглядеть спеца через CV нельзя. Отказат же - запросто. Отнести себя к братству программистов через знание синтаксиса одного из языков, все равно, что причислять себя к категорте русских писателей, размахывая дипломом литературного факультета ВУЗа. Программистами рождаются. Кодированием же (к примеру графическим) может заниматься и обезьяна. Дискавери часто показывает подобные сюжеты.

Абсолютно тупиковая тактика.

Среднеквадратичное значение (эффективное значение, RMS) - используется для измерения переменного тока и напряжения. Приборы, измеряющие такое значение, имеют маркировку ╚True RMS╩, дешевые ╚китайские╩ мультиметры измеряют среднеквадратичное значение только для синусоидальной волны, для несинусоидальных значений, они имеют значительную погрешность

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

А мне нравиться.
Особенно про музыканата

Правда, сомнительно, что всем (дискутирующие не в счет ) даже при 24 часах занятий программированием в день удастся стать Кнутом или Виртом. Я, например, не стал, хотя занимаюсь много.

Моя реплика по поводу RMS была таким же нонсенсом, как и реплика одного из участников по поводу поиска курсов (2-ое сообщение) Я не отношу себя к Кнутам по простой причине, т.к. их не знаю. На Вашу откровенност моя откровенность. Программирую с 1968 года. Первая машина на которой программировал - "Проминь". Затем шли Мински, ХП, Ванги, ЕС, Электроники и.т.п. Код никогда не был проблемой, проблема была в поиске компромиса между машинным ресурсом и алгоритмом. Сегодня такой проблемы практически нет. Вместе с тем, алгоритм остается проблемой. Получить образование по всем алгоритмам нельзя (да и не нужно). Программист это программист. Того господина могу научить программированию и дать сертификат.

Я не отношу себя к Кнутам по простой причине, т.к. их не знаю
Это печально... Особенно учитывая 27-летний опыт.

А вот тут я не соглашусь. По моему глубокому убеждению человека нельзя научить программировать, так же как нельзя научить рисовать, сочинять стихи, музыку и т.д.
Человека можно научить кодировать, но не программировать.
Что касается остального
я это как раз и имею ввиду под фундаментальным образованием, когда тебя учат решать не те задачи, решение которых известно (по этим я и понимаю "кодирование"). А когда ты получаешь знания методов решения задач, да еще можешь применять их на практике, то это программирование, в т.ч. и алгоритмов.
Многие, правда, уже до нас Кнут разработал. Занимательная книженция, должу я Вам. Читал в свое время в читалке, т.к. на руки не давали, один экземпляр на город был, а перфоленты по телефону не передавались. И consul 400, что на Наири-3 стоял ух как медленно печатал.

Опыт правильно подсчитали, а вот про "печаль" ошиблись. Пауза ... Стоит ли акцентировать внимание на подтекст?

Можно, если знать мотивацию объекта обучения.

Хммм... Вообще-то - 37-мь лет, но... хммм... последние лет 20-ть товарищь просто не писал. А полная дисквалификация, как общеизвестно, в ИТ наступает максимум в течении трех лет бездеятельности.

Освоив их, вы заткнёте за пояс очень многих программеров с высшим образованием:-)
-----
Если считать что идет разговор об ВО, а не об крочке об отбытии n-ного количества часов в указанном ВУЗе, то шансов "заткнуть кого-то за пояс" - практически никаких. При всем желании невозможно в обозримые сроки изучить все необходимые дисциплины и связи между ними. Хорошим кодером - да, можно стать самостоятельно. Стать же Программистом, самостоятельно, без хорошего профессионально поставленного тренинга, практически невозможно.

Я, например, не стал...
-----
Еще не вечер!
Если ты не в курсе, то Кнутт, занимался обучением и планировал написать 12-ть томов. Вышло - всего три. Так что - еще не вечер!

Самый уважаемый мною программист (из тех кого знаю лично) имеет около 35 лет стажа, не знает С++, а Java для него лишь остров в океане и, возможно, напиток. Пишет на С. Ни ООП с ООА, ни прочая новомодная лабуда его не интересуют вообще. Больше всего программирует карандашом в тетрадке в клеточку. Иногда по нескольку лет не пишет конкретного кода. Зато программный комплекс, разработанный под его руководством, был способен на 286-ой с 1MB оперативной памяти и 20MB-диском производить векторизацию карт размером 20000x30000 пикселей (в несжатом виде одна такая карта занимает порядка 70MB). И работала программа максимум десяток минут. Подобные векторизаторы на Западе работали по нескольку часов на появлявшихся в то время Pentium'ах с намного большими ресурсами и лишь на намного меньших картах.
Самый неуважаемый мною программист (опять-таки, из тех кого знаю лично) закончил универ в Германии и защитился в ETH. На столе у него есть все самые популярные книги по объектно-ориентированному программированию. Он действительно спец по ООП и всегда поддерживает свой уровень, интересуется всеми новостями из этой области. Но когда мне приходится что-либо править в его коде (очень легко читаемом и прекрасно документированном, прям как в учебнике), то предпочитаю выкидывать все подряд. Этот красивый код с морем классов и шаблонов, со стандартными паттернами и соответствующий всем мудрым правилам из "Effective C++" и прочих умных книжек в большинстве случаев решает либо не те задачи, либо неправильно, либо требует совершенно нереальных ресурсов.
Если судить лишь по коду, по знанию актуальных технологий и по времени, проводимому за непосредственным написанием кода, то первый из упомянутых программистов давно дисквалифицирован, а второго возьмет на работу практически любая солидная IT фирма. Хотя для меня все выглядит наоборот: первый - Программист, поскольку умеет решать задачи, а второй - обыкновенный кодер.

Хорошо, еще раз. Программист, не работавший три года, теряет квалификацию настолько, что к промышленному производству софта более не пригоден. Более того, к тому же пром.производству софта непригоден программист, не проходивший переобучение более 5-6 лет.
Промышленное производство софта - выполнение определенного объема разработки во вполне определенные сроки, мало зависящие от типа (отсюда, разумеется, исключаются компрессии с райтом 1:1000 и аналогичные, не типовые задачи) задачи.
Оценивать людей, не видя их работы я не берусь.
Пример плохого программиста. В свое время я написал лексико-синтаксический нанализатор для некоторого подмножества Си. Ближайшие аналоги, в то время, занимали порядка 60-70 килобайт си-шного кода без коментариев. Мне удалось уложиться в ЧЕТЫРЕ страницы - одна содержала описание использованной методики и схему операционистики, одна - таблицу определений операций со всеми их атрибутами, одна - эквивалент BNF-нотации для неоперационной части языка, оставшаяся - код. Вся схема - вполне рабоспособная. НО(!) на моей памяти ни один из программистов, с весьма приличной квалификацией, не смог разобраться в том - КАК она работает и почему она ФУНКЦИОНИРУЕТ ПРАВИЛЬНО... хотя там простой автомат на 16-ть состояний. Ну что поделаешь - я был молодой, начинающий программист и не знал, что так делать нельзя, а надо строить матрицу инцидентности, потом выполнять транзитивное замыкание, проверять неоднозначность грамматики и т.п...

Очередная байка о гениальных советских программистах Только почему-то все эти гении никаких заметных следов после себя не оставили, кроме Степанова никто и на ум то не приходит...

Очередная байка о гениальных советских программистах
-----------------------------------------------------------------------------------
Очень интересная реплика. Ее даже не нужно коментировать, т.к. достаточно приводить примеры. Уверен, кроме Кнута Вы читаете и другие книжки. Для Вас, вероятно, Билли является авторитетом в программировании? Для меня он отличный пример удачного (изощренного) бизнес-менеджмента. Я, если Вы еще не поняли, программирую без перерыва с указанного года по настоящее время. По поводу Била Вы согласны?

Для Вас, вероятно, Билли является авторитетом в программировании?
Нет, не является. Для меня это скорее такие люди как Alexandrescu, Sutter, Fowler.

Самый уважаемый мною программист (из тех кого знаю лично) имеет около 35 лет стажа, не знает С++, а Java
---------------------------------
Могу добавить. Сейчас!!!! работаю с человеком, которому за 69. Когда мы садимся за бундулис (ПЭВМ на местном жаргоне), я с удовольствием выполняю роль кодера. Он рассуждает, а я пишу. В результате получается программа практически без ошибок. А если таковые появляются, отношу их к своим. Он не пользуется Интернетом и не программирует. Ранее он программировал и очень даже хорошо. По его книжкам "некоторые" и сейчас учатся науке терминального управления.

Нет, не является. Для меня это скорее такие люди как Alexandrescu, Sutter, Fowler.
---
Вот и хорошо. А тех, как Вы сказали "советских", не знают по простой причине - были засекречены и в прямом и переносном смысле этого слова. Вам не приходилось отдавать в печать свою работу? Если да, то Вы должны были бы это знать.

Так называемая "лабуда" имеет вполнее обосновaнные причины появления на свет. Если чьё-то узколобие заставляет думать, что настоящие программисты пишут только на ассемблере, то это ничего кроме узколобия не показывает. Если знать количество человеко-часов потраченных на разработку того проекта, то можно хоть как-то было бы сравнить с трудозатратами в современных проектах - взять какой-нибудь incscape и посмотреть, сколько времени было затрачено на напсание модуля векторизации. И уже потом оценивать, насколько эффективно всё было решено. А так, простите, это нифига вообще не говорит.
Вы полагаете сейчас оптимизация это _проблема_ и удел гениев?? Реалии таковы, что сейчас в первую очередь считают стоимость проекта, и если есть необходимость, то и соптимизируют. Просто, часто гораздо дешевле более мощный компьютер купить, чем убить кучу денег на потраченное программистом время.
И знаете, когда я работал в совке на заводе, мы сплошь и рядом повторяли подобные "подвиги", начиная от построения графов из десятков тысяч узлов и сотен тысяч связей между ними и отображая это в сибилдеровском тривью, делая это за несколько секунд вместо десятков у "конкурентов"; делали графические редакторы, которые отрисовывали на вторых пнях порядка десяти тысяч полигонов и не только за десяток-два милисекунд. Против нескольких сотен у "конкурентов". А когда надо было особо воображение чьё-то поразить начинали выравнивать данные на границу параграфа и следить, чтобы данные в кэш влезали. Эт помимо алгоритмической оптимизации. Только это не говорит ни о чём, кроме того, что у нас было время и возможность ковырять всё это. Вот, если кто-то в рашше сделал бы что-нить типа CORBА - вполне себе навороченная промышленная система, вот было бы достижение, когда можно было бы сказать: да, вот, это круто. А так, это сказака о советских программистах.
2scorpi_: Степанова и того можно с натяжкой называть советским. Он же разработал STL будучи в HP и не один, а совместно с М. Ли и Д.Р.Муссером.

Без кода кроме личных пристрастий это ни о чём не говорит.

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

Простите, а какое отношение Билли имеет к? Его интерпретатор Бейсика в состоянии повторить школьник, при условии, что он достаточно увлечён. Или Билли, что-то ещё написал?
А как удачный бизнесмен, это да, хороший пример.

Ну, хорошо. Куда делось-то всё после падения железного занавеса? Где наша операционная система хотя бы? Что у нас есть кроме ГОСТ -ов каких-то там в области криптологии?
Если захотите возразить, прочитайте, пожалуйста, статью и скажите с чем несогласны: http://www.znanie-sila.ru/online/issue_741.html
Вот Вам и вся наша компьютерная отрасль. Обратите внимание, на основной упор на железо и как всё подохло, в том числе и потому, что наворовать не смогли в достаточной степени ПО, когда был создан в 1968 году Научно-исследовательский центр электронной вычислительной техники и был взят курс на совместимость с зарубежными аналогами.
p.s. Вы, ведь, знаете как у нас UNIX появился? И VAX/VMS?

Зачот! Тема раскрыта!
PS Степанов оказывается аж в 1977 свалил в США. Ну ладно, хоть образование у него советское

Если захотите возразить, прочитайте, пожалуйста, статью и скажите с чем несогласны: http://www.znanie-sila.ru/online/issue_741.html
Ты знаешь, статья цитирующая Бабаяна в качестве эксперта, для меня в значительной степени лишается достоверности...

Он рассуждает, а я пишу.
-----
Хи-хи... Поверьте, что вы _нормально_ не пишите уже лет 20-ть - с момента появления первых С++ трансляторов.
В результате получается программа практически без ошибок.
-----
Угу... Только добавте, плс, без синтаксических ошибок. Я, например, без них писать не умею. Вообще. И меня это не беспокоит, поскольку уже давно не "работаю транслятором".
Что же до кода, написанного _под диктовку_, то, скорее всего, проблемных мест в нем не просто не мало, а надо искать где именно в нем нет проблем. Так будет всегда, пока не сделана и не оценена постановка задачи.
Несколько раз мне случалось работать/возвращаться к коду, который был наработан подобным образом. После анализа задачи обычно находилось много весьма проблемных мест, а после переработки код в объеме в три-пять раз, система в целом начинала работать на порядок-другой быстрее. Следующий же подход к тому же коду хотя и выявлял новые проблемы, но почти все они были связаны с неточным понимаем поставленной задачи и исправлялись, если это не требовало полной переработки проекта, в считанные дни.
Перечитайте Вокселя - основной упор - на размер трудозатрат по реализации поекта. Бо, стоимость необходимого железа несравнимо низка даже по сравнению со стоимостью нормального кодера.
По его книжкам "некоторые" и сейчас учатся науке терминального управления
-----
Да-да, учатся строить асинхронные автоматы. 3-й курс рижского политеха, увы недостижимый для выпускников Технического Университета (для тех кто не в курсе - политехнический институт в риге был гордо переименован в уни после переворота, текущая программа обучения примерно соответствует средней школе образца средины 70-х).

А так, простите, это нифига вообще не говорит.
------
Вспоминается одна байка.
Бабуля-учетчица хвастается перед другой такой же бабулькой:
- Ой, а ты знаешь у нас новый Программист!!!
- ???
- Он такой лапушка, он нам Ворде все так КРАСИВО сделал...

и был взят курс на совместимость с зарубежными аналогами.
-----
Надо все же сказать, что еще были и Эльбрусы. И не забыть об том, сколько нормативных сроков на орбите выработал МИР...

Хи-хи... Поверьте, что вы _нормально_ ...
--------------------
Вы высказались? Молодец! Я Вам верю.

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

Тяжело представить себе современного программиста, не пользующегося интернетом. Мне пришлось по долгу службы столкнуться с техзаданиями на софт от БМВ и от Хенкеля. Как Вы думаете, упоминается ли там интернет? Ваш коллега будет наверное удивлен, что данные храняться отнюдь не в текстовом файле и что для телефонов можно писать не на ассемблере.
Мне Ваш пример напомнил поговорку: с вилами на паровоз.

В очередной раз завязался спор на тему, которая не имеет решения - единого мнения. Вы, живущие в Германии, помогите парню найти курсы.

Когда мне есть кому-то что-то сказать по теме, я это сразу говорю. И здесь я не только беседую на отвлечённые темы, но ещё и иногда даю ответы.
Кто, что знал, уже сказали. Я не знаю ничего о курсах Германских, т.к. не имел необходимости подобнoе искать. От того, что мы беседуем не по теме, хуже парню не станет, наоборот, ветка провисит гораздо большее количество времени и вероятность того, что новый человек, который будет знать ответ на первоначальный вопрос, придя в конференцию подскажет ему что-то дельное, увеличивается.
p.s. Пардон, девушке.

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

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

ко всему (ниже-/выше-)сказанному добавлю, что программисты, которые не пытаются освоить новые технологии, у меня всегда вызывали недоумение. И они могут быть 100 раз талантливыми и создавать отличный софт, но эти люди обречены на *одиночество*. Одиночество в том смысле, что они рано или поздно окажутся в ситуации, когда уже никто не захочет быть с ними в одной упряжке:-)
Выжить таким возмоможно разве что только в очень узкоспециализированном направлении. Где из-за недостатка *схавают* и старые технологии.
К этому, кстати, и *лабуда* относится:-). Кто и как ее применят не уменьшает ее заслуг в области программирования.
С программистом, который не знает ООП, сейчас мало кто хочет работать. Потому что он будет тормозом.

по поводу ВО я с тобой не согласен:-)
Возможно где-то в другой вселенной есть Уни, где собраны в одном лице не только талантливые ученые, но и талантливые преподаватели, но не в нашей 8-)

Первый никому не нужен, хоть памятник поставьте ему.
Ну, например, в Уни какой-то могут взять, работать на кафедре :-)

что для телефонов можно писать не на ассемблере.
-----
??? - Как можно что-то писать для той бандуры у которой надо крутить ручку с боку?

Вы, какжется, говорили, что можете _обучить_... если будете знать мотивацию.
Мотивация - указана в запросе - косвенно определен класс интересующих задач.
Мне бы вот что было бы интересно узнать - возьметесь ли обучать, при условии,
что если обученный вами специалист будет зарабатывать меньше 125% средней
зарплаты, то разницу вы ему будете доплачивать? Поправку на то, что там не
парень, а девица просить будете?

по поводу ВО я с тобой не согласен:-)
-----
Можешь не соглашаться. Правда было бы не плохо хоть чем-нибудь аргументировать. Ну скажем тем, что тебе никогда и нигде не потребуется понимать и разъяснять смысл наложения рефлексивного замыкания поверх транзитивного...
P.S. Я не знаю, что и как у вас. Я знаю - как учили меня и знаю насколько велика разница между тем что было и тем что есть сейчас в _тех же_ ВУЗах.

Ну, например, в Уни какой-то могут взять, работать на кафедре :-)
-----
А смысл? Что будет на "выходе"?

ну, если чел талантливый, то на *выходе* будет решение проблемы:-)
В Уни на кафедрах иногда пытаются найти решения вопросов, которые еще никто не нашел. Поетому будут рады любому решению, пусть даже на языке С 8-))
И не редко такие проекты делает один чел, т.к. пока нет решения (в обозримом будущем), эта тема никому на фиг не нужна:-). Хотя и все хотят заиметь решение:-)

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

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

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

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

аргумент один - квалификация преподавателей.
Не как ученого, а именно как преподавателя. Совсем не редкость, когда чел отличный ученый и бездарный препод в одном лице. Но т.к. он профессор, то ему и дают читать лекции.
Такие люди либо убивают интерес к своему предмету, либо вынуждают студента учить предмет самому. А чем это отличается от самоучки вне стен ВУЗа? Уже вполне доступны любые книги, которые разжeвывают любую тему.
Что касается того, как и чему учили раньше и сейчас, то тут, наверно, стоит заметить, что ассортимент все время увеличивается и все выучить нереально:-))

В Уни достаточно людей, которые не имеют с процессом *выпуск специалистов* ничего общего 8-)
Они ищут решения вопросов, в которых Уни имеют свои интересы. И тут вполне могут себя найти *теоретики* от программирования:-)). Их задача найти решение и зачастую форма решения и сроки уходят на второй план.
Ты возьми программистов с высшим образованием, которые годами работают в Уни над решением таких проблем, и брось их в Industrie. Ты ужаснешься от *выхода* :-))
Многие из них не умеют работать в команде и под прессом сроков.
Но в своей стихии (неторопливая работа в одиночку) они незаменимы:-)

Но реальности таковы: наш программно-аппаратный комплекс используется в операционной во время нейрохирургических вмешательств и всякие суперкомпьютеры и кластеры не помогут - для них просто нет места, да и стоимость комплекса не позволяет наращивать вычислительные мощности. А стремление коллеги использовать все эти шаблоны (библиотеку CGAL да и тот же STL) приводит к тому, что система, которая в идеале должна работать в реальном времени, зависает иногда на несколько минут. Решать большинство задач оптимальным для нашего комплекса методом - единственный выход, а все стандартные библиотеки (уж тем более реализованные в виде шаблонов как CGAL) просто абсолютно не пригодны. Но вот с решением задач проблема.
-----
По порядку.
Подо что у вас есть место? Полагаю, что раз уж система используется, то по крайней мере один комп имеется в наличии. Почему - используется компьютер для расчетов на месте, а не терминал или не компьтер в качестве терминала? Отрисовку на экране в приемлемое сделает _любой_ писюк и отрисовывающее ПО не будет тормозить.
Не знаю как влияет использованием CGAL - не приходилось пользоваться, но вот по STL знаю абсолютно точно - неправильное применение STL приводит к весьма неудобному коду, пожиранию ресурсов и как следствие - тормозам. Однако я не уверен, что из произвольной выборки в 100 программистов, хотя бы 3 смогут, в пределах того же ТЗ, написать более качественный, компактный и быстрый код. Правда, что более интересно, эти же трое смогут написать нересурсоемкий, компактный и быстрый код и с использованием STL.
Проблема не с решением задач - проблема с квалификацией исполнителей.
Первый уже достиг практически всего, чего хотел. В силу давно уже пенсионного возраста работает лишь консультантом в свободное время.
-----
Если ваш комплекс имеет проблемы, а по описанию он их имеет, вероятно, что что-то не так в организации разработки. Поскольку здесь даны ссылки лишь на двух людей, один из которых отслеживает последние нововедения, а другой об них даже не слышал, то, на мой взгляд, проблема скорее всего в понимании вторым стоящих задач и возможных способов их решения.

У нас на фирме постоянно были вакансии для программистов. Последний раз приняли нового человека больше двух лет назад, хотя желающих всегда много. Официально среди требований числятся ООП/ООА/UML/C++, но на эти знания у нас смотрят чуть ли не в последнюю очередь. Если человек не способен самостоятельно решить задачу, то кому нужны все эти умения использовать шаблоны, рисовать диаграммы? Да и диаграммы чего? Нанять фирме сразу еще одного программера, который будет решать задачу, разрабатывать эффективные структуры данных и алгоритмы и разжовывать этому ООП/ООА/UML/C++ ассу решение пока тот не сможет нарисовать красивую UML-диаграмку и кучу классов с шаблонами? Подобная ситуация на фирмах у большинства моих коллег.
Интересно, ядро Linux'а уже на С++? Объектно-ориентированно и со всеми UML диаграммами? Или там все тормозят?

аргумент один - квалификация преподавателей.
----
Эээ... жалуясь на недостаточную квалификацию преподавательского состава ты предлагаешь доверить преподавание неспециалисту.
Уже вполне доступны любые книги, которые разжeвывают любую тему.
-----
Книги были доступны всегда. Но вот беда - соременные - разжевывают в виде - сделай так, сделай вот так, теперь вот так - ты получил результат. Почему надо делать именно так - не объясняют и объяснить не могут - их авторы, зачастую, и сами не знают почему надо делать именно так. Вот на полочке лежит книга по использованию XML для веб приложений. Двое авторов. Где-то после 2/3 книги приводится JavaScript'овый код, режущий XML документ и вставляющий в начало кусок текста - стандартный заголовок XML-документа. Автор(ы) чесно написали - это неправильный подход, но мы _не_ знаем как другим способом вставить стандартный заголовок в документ... Найти ссылку на стандартный метод вставки заголовка - <PI ...> - тоже видимо не смогли - не было другой книжки в которой написано - сделай так...
и все выучить нереально:-))
------
Все выучить _самостоятельно_ за приемлемое время - нереально. Именно по-этому определением того, чему надо обучать, в какой последовательности преподавать и самим обучением должны заниматься профессионалы - т.е., как минимум, ВУЗ.
Эээ... В тех ВУЗах, на которые я ссылаюсь, ассортимент "слегка" сменился - в связи с тем, что школы выпускают людей вообще без сколь-нибудь значимых знаний в области "технических" дисциплин - математики, физики и химии - готовят бухгалтеров, юристов и прочих бла-бла-благодетелей...

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

Интересно, ядро Linux'а уже на С++?
-----
Задайся другим вопросом - почему официально считается, что работу ядра *nix'а понимают всего человек 10-12 в мире.

ты предлагаешь доверить преподавание неспециалисту
ыыыыы...убей себя в моск %-)
ну, прочитай еще раз, чтоб ты понял, где этот чел будет работать 8-)

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

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

Сижу, вкуриваю... Вы видите применение контейнеров только в том, чтобы иметь возможность сортировки?

Всё он понял, если Вы не знаете, что в C++ Вы имеете такую же свободу в управлении памятью как и в С, то совет почитать документацию вполне разумен.

есть небольшой оверхед при вызове виртуальных функций
-----
а в С та же функция вызывается через указатель.
=====
1. Читай внимательно. Ключевое слово - виртуальные.
2. В том же Си можно получить обе имплементации. Руками, правда...

У нас море шаблонов в проекте, но практически все они используются лишь единожды
Пооже Вы на самом деле не понимаете для чего нужны шаблоны...
Для некоторых из них задана операция сортировки (std::list<>::sort()), но упорядоченность имеет смысл не всегда.
Кто же заставляет Вас использовать данную функцию? Если Вы её не используете, то приличный linker её в executable и не включит. Кроме того, Вы видимо не понимаете почему std::list имеет собственную функцию сортировки?
Если для объектов класса Object задать операции сравнения невозможно (и не нужно), то можно ли использовать контейнер std::list<Object>?
Одно из преимуществ использования STL - как раз возможность отказа от общего предка -> flache Klassenhierrarchie -> strengere Typisierung.
каким-то образом ограничивать использование std::list<Object>
При приличном дизайне все классы имеющие наследниковв должны быть абстрактными. Тогда и проблем таких не возникает.
Или такой пример: операция нормализации для шаблона Vector3D<> имеет смысл?
Вы не знаете как запретить использование какой-либо операции для определённых типов?

Я же не оспариваю справедливость твоего высказывания, просто дополняю. Впрочем если говорить о виртуальных функциях в С++, то надо приводить эквивалентный дизайн в С.

Как можно при этом что-то гарантировать относительно времени реакции системы?
-----
Опсс... Если уж вы делаете систему, которая, по вашему утверждению, будет использоваться в операционных, то "ограниченность рессурсов" явно отходит на дальний план перед веменем реакции.
но получается программирование для С++, а не использование С++ для реализации решения конкретной задачи.
-----
Вы нашли в этом плане какие-то бенефиты при использовании "чистого Си"?
А также "оверхед" программирования шаблонов
-----
Читайте Скорпи. От себя добавлю, что можно принудить компилятор инлайнить специфические функторы.
Вы просто не поняли в чем состоит проблема фрагментации адресного пространства.
-----
Я бы давно уже не работал Программистом если не понимал этой проблемы и не знал как с нею обходится.
P.S. Тут на форумах уже трое программистов говорят вам, что ООП-решение/реализация нисколько не проигрывает функциональной. Стоит подумать над этим...

Впрочем если говорить о виртуальных функциях в С++, то надо приводить эквивалентный дизайн в С.
-----
Топорно он описан выше - vtable против массива указателей.

Да я в курсе, если мне не изменяет память Netscape был таким макаром на С написан...

в C++ Вы имеете такую же свободу в управлении памятью как и в С
-----
Как ты писал выше - более гикую.

если мне не изменяет память Netscape был таким макаром на С написан...
-----
Я посмотрел объем соурсов... и стиль... и решил что мне не хочется в этом разбираться...

Мне тоже не хочется Я как-то хотел поучаствовать в написании Лисы, но посмотрев исходники от этой идеи отказался. Не в последную очередь потому-что вместо использования STL они изобретают велосипед и пишут всё сами. Мотивируя этот шаг гипотетическим использованием Лисы на каких-нибудь экзотических платформах, где STL отсутствует...

При том объеме, который имеют исходники Лисы... хммм... легче портировать STL на другую платформу... даже при условии, что придется делать и компилятор.

Нет. Я использую С++ и ООП, но лишь там, где это дает явные преимущества. Общие решения не могуть быть эффективней частных. Готовые шаблоны CGAL/STL в нашем конкретном случае не эффективны. Конечно, ту же нашу специфическую сортировку можно было бы оформить в виде шаблона, но совсем нет необходимости, времени и желания думать сейчас о том, как этот шаблон мог бы работать с другими типами данных в будущем. Тем более, что данный метод сортировки применял всего лишь дважды до этого - в программах на ассемблере и на Java. Чем в тех случаях помог бы готовый С++ шаблон?

Общие решения не могуть быть эффективней частных.
Общие решения в виде шаблонов дают более высокую производительность труда при более высоком качестве кода и неизменной скорости исполнения кода.
Готовые шаблоны CGAL/STL в нашем конкретном случае не эффективны.
Так всё таки, в чём это заключается? Пример с сортировкой мы опровергли, с использованием памяти тоже. Что ещё?
но совсем нет необходимости, времени и желания думать сейчас о том, как этот шаблон мог бы работать с другими типами данных в будущем
Прелесть в том, что об этом думать как раз и не надо. Мне впрочем аж интересно стало, что за алгоритм-то там использовался?
Чем в тех случаях помог бы готовый С++ шаблон?
Возможностью использования его со стандартными контейнерами. Кстати, вопрос - в чём Вы храните данные?

Я использую С++ и ООП, но лишь там, где это дает явные преимущества.
-----
Ну хорошо, еще раз. Нет у "чистого С" никаких преимуществ перед С++. Вообще нет. Это тестилось неоднократно и всегда получался один и тот же результат - нет никаких преимуществ у "чистого С", нет провала в производительности при использовании С++. Все остальное - квалификация исполнителей и понимание ими задачи.
У особо упертых я обычно спрашиваю - вы понимаете, что все, что вы кодируете, суть - автомат(машина состояний с памятью) и что разные языки всего лишь разные инструменты определения этого автомата? Входные и выходные данные у вас одни и те же и алгоритм преобразования - тот же...
Конечно, ту же нашу специфическую сортировку можно было бы оформить в виде шаблона, но совсем нет необходимости, времени и желания думать сейчас о том, как этот шаблон мог бы работать с другими типами данных в будущем.
-----
А в каком месте тут надо думать? Тут всего лишь надо затратить тоже самое, максимум х1.3, время на оформление кода в виде шаблона. Ну а бенефиты... хммм... самый простой - будет единый стиль кода во всем проекте... более сложный - замена вашего алгоритма сортировки на еще более вычурный, без переработки остального кода...

std::deque абсолютно не решает проблемы.
Еще раз о фрагментации адресного пространства. Речь идет о 32-битных системах. 32-битный указатель может адресовать до 4GB памяти. Когда оператор new или функция alloc/malloc/calloc запрашивает блок памяти размером 1GB, менеджер памяти резервирует кусок адресного пространства и возвращает указатель на начало этого куска. Предположим, что это указатель 0x00000000 и он является вполне нормальным указателем. Тогда адреса [0x00000000;0x40000000) зарезервированы под этот блок. До тех пор, пока программа не освободила его, менеджер памяти не может вернуть указатель из диапазона [0x00000000;0x40000000). Если теперь для наращивания размера массива данных до 1.5GB использовать new, то менеджер памяти может быть вернет указатель 0x40000000 и адреса [0x40000000;0xA0000000) будут зарезервированы под этот новый блок. Затем происходит переписывание данных и освобождение первого блока. Последующая попытка расширить блок при помощи оператора new до 2GB не пройдет, хотя в системе есть еще 2.5GB. Просто эти 2.5GB разбиты на два блока размером 1GB (адреса [0x00000000;0x40000000)) и 1.5GB (адреса [0xA0000000;0xFFFFFFFF]), а нужен один размером 2GB. При использовании realloc в описанном выше случае проблема фрагментации не возникнет. В рамках new/delete я решения не вижу. Аллокаторы предоставляют методы allocate/deallocate, но нет reallocate. В std::deque наращивание зарезервированного блока происходит при помощи последовательности вызовов allocate-copy-deallcoate, что работать не будет.

В std::deque наращивание зарезервированного блока происходит при помощи последовательности вызовов allocate-copy-deallcoate, что работать не будет.
Читайте документацию. То что Вы описываете, это std::vector. Естественно у Вас будут проблемы, если вектору делать resize с 1 гига до полутора.
В рамках new/delete я решения не вижу.
Спросите у специалиста. В пределах 80-90 евро/час Вам окажут помощь. http://www.gulp.de
PS Впрочем я смотрю почасовые ставки упали, так что до 70. Самых дешёвых брать не советую.

Как это относится к задаче обработки медицинских изображений? Почему я должен уделять внимание этим вещам, если в моем случае они явно ничего полезного в код не добавляют? Не добавляют ни сейчас, ни в перспективе.

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

Где я говорил о том, что использую эту функцию? Я говорил об использовании класса std::list<Object>, одна из функций которого явно не имеет никакого смысла (еще раз, речь о шаблоне с конкретным классом Object в качестве параметра, для которого операции сравнения просто бессмысленны).

В огороде бузина, а в Киеве дядька. Зачем мне эта "плоская иерархия"?

Какие наследники? Вы о чем? Хотя... Я понял о чем. О программировании для С++, а не о программировании на С++.
Пардон, но эта дискуссия более совсем не итнересна.

Я в свое время пришел к Berater-у из тогда еще Arbeitsamt-а с просьбой оплатить мне подобное заочное обучение. Объяснил, что мне не столько нужны профессиональные знания, сколько нужна немецекая корочка. Он мне сразу обрубил, что заочные курсы не котируются - мы подберем что-нибудь очное и нашел через пару месяцев. Правда, не очень программирование, не очень качественно, но деньгу платили и слов я там набрался достаточно, т.к. пришлось и Steuer, и Mathe, и Telefontrainig и прочую муть учить, ну прямо как в советском ВУЗе. Это было, правда в Саксонии, а это почти СиСиСиПи.
Я думаю, что Arbeitsagentur проще и выгоднее настойчивого просителя на свои курсы направить, чем выплачивать гос.деньги какому-то фернуниверситету. Им, естественно, безразлично качество, т.к. они себе плюсик поставят, а не кому-то.

Вы не знаете как запретить использование какой-либо операции для определённых типов?
Как это относится к задаче обработки медицинских изображений? Почему я должен уделять внимание этим вещам, если в моем случае они явно ничего полезного в код не добавляют?
Это отражает логику работы Вашей программы. Поможет например избежать того, что кто-нибудь эту операцию использует в неправильной ситуации. Или Вы думаете, что Ваши программисты способны всё держать в голове?
Я действительно не понимаю зачем нужны шаблоны, которым заведомо не будет применения, кроме этого одного конкретного случая и одного конкретного типа параметра.
Применить в данном случае обычный класс запрещает религия? Если это third party шаблон, тогда тем более непонятно почему это Вас так волнует... Или Вы не понимаете как работают шаблоны?
Я говорил об использовании класса std::list<Object>, одна из функций которого явно не имеет никакого смысла
Эта функция Вам спать не даёт? Почему она Вас так беспокоит?
В огороде бузина, а в Киеве дядька. Зачем мне эта "плоская иерархия"?
Более точное отражение реальных объектов, более строгое типизирование -> меньше ошибок.
Пардон, но эта дискуссия более совсем не итнересна.
Естественно, ибо Ваша некомпетентность стала всем ясна.

От Arbeitsagentur вообще нелепо чего-либо ожидать. Самому надо действовать.

/*
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Copyright (c) 1997
 * Silicon Graphics Computer Systems, Inc.
*/
template <class _Tp, class _Alloc, size_t __bufsize>
void 
deque<_Tp,_Alloc,__bufsize>::_M_reallocate_map(size_type __nodes_to_add,
                                              bool __add_at_front)
{
  size_type __old_num_nodes = _M_finish._M_node - _M_start._M_node + 1;
  size_type __new_num_nodes = __old_num_nodes + __nodes_to_add;
  _Map_pointer __new_nstart;
  if (_M_map_size > 2 * __new_num_nodes) {
    __new_nstart = _M_map + (_M_map_size - __new_num_nodes) / 2 
                     + (__add_at_front ? __nodes_to_add : 0,0);
    if (__new_nstart < _M_start._M_node)
      copy(_M_start._M_node, _M_finish._M_node + 1, __new_nstart,0);
    else
      copy_backward(_M_start._M_node, _M_finish._M_node + 1, 
                    __new_nstart + __old_num_nodes,0);
  }
  else {
    size_type __new_map_size = 
      _M_map_size + max(_M_map_size, __nodes_to_add) + 2;
    _Map_pointer __new_map = _M_allocate_map(__new_map_size,0);
    __new_nstart = __new_map + (__new_map_size - __new_num_nodes) / 2
                         +
 (__add_at_front ? __nodes_to_add : 0,0);
    copy(_M_start._M_node, _M_finish._M_node + 1, __new_nstart,0);
    _M_deallocate_map(_M_map, _M_map_size,0);
    _M_map = __new_map;
    _M_map_size = __new_map_size;
  }
  _M_start._M_set_node(__new_nstart,0);
  _M_finish._M_set_node(__new_nstart + __old_num_nodes - 1,0);
}

Это из g++ (cygwin). Так что садитесь scorpi_ - два бала (по русской системе). Куда обращаться за помощью Вы сами знаете.

RTFM, решает. В отличии от вектора, на стратегию выделения памяти которого Вы ссылаетесь говоря о проблеме нехватки памяти, двухсторонняя очередь выделяет память фиксированными буферами под очередную порцию элементов, чтo решает в Вашем случае проблему нехватки памяти.

man operator new, man operator delete. operator new и operator delete! A не new и delete!
Вы уп╦ртый человек, который не слышит, что ему говорят. Пожалуй, только то, что здесь в кои веки пообсуждали C++, а не какой-нибудь отстойный хомяк, заставило Ваших собеседников терпеливо объяснять очевидные вещи, вместо того, чтобы сразу сказать то, чем дискуссия заканчивается: RTFM.

_M_reallocate_map
Ещё раз RTFM. Это реаллокация массива содержащего указатели на блоки (подмассивы).

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
3. Отправлять эти данные дальше в качестве 3D текстуры для OpenGL нереально.
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти и std::deque тут не помощник. (Да, с его блоками я ошибся)
5. В объяснениях я не нуждаюсь - к работе моих модулей претензий нет и помощи в решении проблем я тут никогда не искал. Я лишь описал проблемы того кадра, который упорно применяет свои отменные знания ООП и С++ и совершенно не в состоянии решить саму проблему. Признаюсь, это была глупая затея. Даже если бы я мог выложить в открытый доступ его код, ни к чему бы другому это не привело.

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
-----
Хммм... Как бы это помягче сказать... Наверное так - выполнение calloc/malloc/realloc, в принципе, не гарантирует выделение не фрагментированного участка памяти. Что гарантируется - что выделенная область будет выглядеть непрерывной. Какими средствами достигается эмуляция выделения непрерывной области и каковы при этом издержки на управление - вопрос отдельный.
Вообщем, остается повторится, - читайте доки - от модели процессора, через операционку, до стандарта языка.
Ах, да... совсем забыл... Одно из лучших решений по управлению фрагметированными данными разработано IBM, где-то году в 72-м. Можете ознакомится на досуге.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
-----
Угу... "Самый лучший язык программирования - ассемблер!" Ни один другой язык не дает эффективных решений...
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти
-----
Эээ... У меня есть большое желание дать какому-нибудь студенту-первокурснику задачку отсортировать методом линейной сортировки массив из одного (еще раз - одного) элемента.

Плюс тот факт, что в приведенном примере realloc сможет выделить новую память, а new нет. realloc конечно же не панацея и в общем случае от проблемы фрагментации адресного пространства не избавит, но в этом конкретном - сработает. Просто когда-то были выкинуты из проекта все вызовы calloc/malloc/realloc и все было переведено на new/delete (за исключением моих модулей). Мотивировалось все это тем, что это С, а мы используем С++ и т.д., и т.п. Вобщем та часть проекта в конце-концов стала соответствовать всем критериям качественного объектно-ориентированного кода (пропускали даже через PClint с проверкой на соответствие рекомендациям из "Effective C++"). Но при использовании программы быстро обнаружились проблемы с памятью. Из работающей программы была сделана правильная объектно-ориентированная.
То, что с доками по процессору можно решить эту проблему, я знаю. А переход на 64-битную архитектуру вообще ее снимет и объектно-ориентированный код станет опять рабочим. Только когда это будет...

Это Ваши слова Просто на тот момент не было другой возможности использовать SSE. Сейчас заменяем ассемблер на Intel'овские классы.

Спровоцировали. Было ведь видно, что веду речь об одном непрерывном блоке, а перевели разговор на std::deque и поймали...

А переход на 64-битную архитектуру вообще ее снимет
-----
Ничего он не снимет. Абсолютно ничего. ВаааПще ничего. Ну что у тебя поменяется с того, что вместо адресации 2^32, ты сможешь адресовать 2^64? Ответ - ничего. Те же самые проблемы с той же самой фрагментацией, в том же самом количестве. Тем более, что физической памяти тебе это не добавит, а вот лишних циклов узкой шины - вполне...
Еще раз - послушай не глупых людей - учи матчасть.

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
Без комментариев, так как ясно, что нужды иметь 1,5 GB continuous memory нет.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
С итераторами Вы тоже не знакомы?
3. Отправлять эти данные дальше в качестве 3D текстуры для OpenGL нереально.
То есть glTexImage3D Вы выучили, а glTexSubImage3D нет?
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти и std::deque тут не помощник. (Да, с его блоками я ошибся)
И из-за незнания API ошиблись ещё раз.
Я лишь описал проблемы того кадра, который упорно применяет свои отменные знания ООП и С++ и совершенно не в состоянии решить саму проблему
Почему меня не оставляет ощушение, что Вам просто не хватает образования, чтобы разобраться в его коде?

Apropos Лиса, нашёл сейчас в её исходниках ещё одного сишного "гения" запутавшегося в С++

// C++ sucks! There's no way to do this with a macro, at least not
// that I know, if you know how to do this with a macro then please do
// so...
static const PRUnichar sHTMLTagUnicodeName_a[] =
  {'a', '\0'};
static const PRUnichar sHTMLTagUnicodeName_abbr[] =
  {'a', 'b', 'b', 'r', '\0'};

...at least not that I know...
-----
That is a keyword.

// C++ sucks! There's no way to do this with a macro, at least not
Это одна строка. Этот ####### форум вставляет в преформатированный текст лишние переносы строки. Я год добивался чтобы этот баг исправили, весной они наконец-то это сделали. А недавно видимо скопи-пейстили этот баг обратно. Бардак-с.

Ага, надействуешься тут сам, когда на цены курсов посмотришь.

Ба! Встретил наконец-то знакомое слово - эмуляция Мы, все ближе приближаемся к определению (формальному) программирования как отображения (можно и гомоморфного) объекта в среду отображения (компи). Кто добавит уточнение(я) в мое определение в столь свободной форме? Если, конечно же, оно имеет хоть какой-то смысл. А вообще, хорошая программа - это работающая программа.

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

Спасибо и за это. Так и хочется задать СЕБЕ (себе, ...) вопрос - Чем это я занимаюсь всю свою жизнь? Возможно, пора бросать? Некоторые прочтут и ответят, что ТЫ мол и не начинал. Таковы жестокие правила и ... этого ФОРУМА, а может быть и самой ЖИЗНИ?

Это воспитание последних 15-ти лет... И с вами Я весйма видержанно-мягок...

А у Вас были возражния по ключевым моментам спора с человеком?

Глушков, Цейтлин, Ющенко. "Алгебра. Языки. Программирование". Есть и другие источники, но этого достаточно. Это по поводу формализаций. Если мой склероз, отдыхает.

Как -то, спасая проект, успешно заваливаемый одним "продвинутым" программистом, пришлось написать эмулятор мультиплексного канала ЕС... (IBM 360). Алгоритм работы этого ящика (стойки) идеально подходил под алгоритм работы сетевого коммутатора. Делайте скидку на 80 годы. Конечно же, я не отрицаю диалектику в том числе и в терминологии. Пока коментов нет. А ту книжечку почитайте, если найдете.

IRULAN, как мы видим, НАРОД слинял на другие темы. Не смотря на то, что обещали оставаться до победного конца - ответа на Вашу мольбу. Я не могу ответить на прямой вопрос, но, если есть желание, попытаюсь спасти тему следующим вопросом-просьбой. Этот вопрос имеет прямое отношение к тестированию "будущих" (действительно) программистов - пришлите любой рисунок, который можно сделать путем срисовывания с реального объекта. К примеру - вид из окна. Желательно прорисовать контуры увиденного. Увиденное может быть и воображаемым.