Четко? ЭТо вы математику говорите?

Большинство бывает относительное и абсолютное. Продолжить?

esperant0, 
продолжайте
по поводу большинства...
имеется в виду абсолютное

Добавлено через 3 минуты и 30 секунд
esperant0, 
вы бы вместо того, чтобы разводить демогогию, ответили бы по существу и по теме

я не вижу никаких причин использовать С++ в низкоуровневом программировании
в первую очередь потому, что С++ слишком тяжеловесен для написания приложений системного характера
(а если все тяжеловесные фичи убрать, по сути как раз и останется С)
к тяжеловесным моментам я отношу:
1. исключения
2. полиморфизм
3. шаблоны
структуры С вполне заменяют классы С++, агрегирование реализуется легко и непринужденно на этих же структурах
примеров применения наследования в драйверах и прочих низкоуровневых приложениях не встречал (если вы встречали, поделитесь)
как вариант, использование С++ как типобезопастного С
возможно, но зачастую в низкоуровневых программах типобезопастность только мешает 

А кто-то другой наоборот видит эти причины. Мне кажется, это дело разработчика - использовать в низкоуровневом программировании С или С++.
К несчатью (или к счатью) Я не владею техникой процедурного программирования, поэтому никогда и низачто не буду писать на чистом С. Если бы Я драйвер писал, Я бы на С++ его делал (Хотя не исключенно, что в этом случае размер будет побольше, а скорость поменьше, но это опять-таки смотря как написать). Те же исключения в драйверах - очень полезная вещь, там как раз больше всего исключений приходится обрабатывать. 

WERITAS, 
назовите хоть одну действительно объективную причину использования С++ в низкоуровневом программировании

1. ООП - это по сути синтаксический сахар, синтаксическая надстройка над функциями (=методы) и структурами (=классы)
непонятно, как можно использовать ООП и не владеть "техникой процедурного программирования"   
2. Вы когда-нибудь занимались разработкой драйверов и прочих схожих вещей?

как мне кажется не очень правильный вопрос. причиной может быть всё то, что ты отнес к "тежеловесным моментом". это дело вкуса и доступных инструментов.

Тут есть совокупность множества причин - проссумировав которые скажу, мне УДОБНО.

вот еще, по поводу исключений
не знаю как в VC++ и прочих виндовых компиляторах, но в GCC для реализации исключений
используются функции из libstdc++ (которая, кстати, весит довольно прилично)
если учесть, что драйвера в принципе не могут использовать подгружаемые библиотеки, то единственным вариантом использования исключений остается статическая компоновка libstdc++ вместе с драйвером
а это очень нехило увеличивает его размер   
esperant0, 
"мне удобно" - это не объективная причина
объективные причины не использовать мною были названы   

инструменты...может быть, но мне лично трудно себе представить, что С++ компиялтор есть, а С - нет
вкусы...
усложнение кода и снижение производительности в таких вещах ради вкусов?   
я могу понять выбор между Java, C#, С++ (или еще чем либо) в плане предпочтения по принципу нравится/не нравится в прикладном программировании, но в системном...

есть и тот и другой на выбор

для кого-то pattern based development гораздо проще чем процедурщина. хотя конечно гики и там смогут наворотить. да и потом,  кто сказал, что в низкоуровневом-системном программировании нужна максимальная производительно? это лишь одно из многих возможных качеств продукта.

Предлагаю разделить тему на то, что я предложил к обсуждению и "C vs C++ в низкоуровневом программировании".

Первое меня интересует, второе - нет.

тогда к чему было сказано о доступности инструментов?
я так понял, что С-компилятора может не быть, поэтому придется писать на С++
или я не так понял?

это по определению   
системное ПО предоставляет сервисы для работы прикладного ПО или само является сервисом (виндовые сервисы я не имею в виду   ), а значит не может себе позволить расточительно расходовать системные ресурсы
исключением является, пожалуй, сетевое программирование (не имеется в виду создание стека протоколов), где потери производительности можно отчасти нивелировать пропускной способностью канала

Добавлено через 50 секунд

  

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

Забрел на один сайтик (спасибо Vingrad-у). В одном из разделов там предлагаются к ознакомлению рейтинги зарплат по различным критериям. Вот на какие направления там разделяют индустрию разработки программного обеспечения (данные по зарплатам брались за 2007 год):

• Аутсорсинг
• Разработка ПО (аутсорсинг)
• Разработка ПО
• Веб-разработка
• ИТ
• Телекоммуникации
• Банковская сфера
• Финансы
• Торговля
• Embedded
• Промышленность
• Продажи
• Разработка игр
• Транспорт
• Дистрибуция

Ссылка

Жду ваших мыслей по теме. 

LSD, я просил.. 

Это сообщение отредактировал(а) S.A.G. - 23.10.2007, 17:33

нет, не лучше
1. Ассемблер не переносим
2. Ассемблер себя не оправдывает в большом проекте: трудность отладки, повышенная вероятность наличия скрытых ошибок, трудоемкость процесса разработки
ассемблер используется там, где напрямую на С написать не получится либо нужна очень сильная оптимизация
но таких участков кода обычно мало (либо нет совсем)
по поводу объективности
использование преимуществ С++ ведет к раздутости кода и снижениюю производительности, что для приложений системного характера недопустимо (в большинстве случаев)
это не объективные причины?   
если преимущества С++ не использовать, чем он в итоге будет отличаться от С?   

Это сообщение отредактировал(а) MAKCim - 23.10.2007, 21:18

Для истинной кросплатформености надо писать драйвера на Java  
Мне вот интерестно какой процент общего кода у драйверов видеокарт для маков (те которые на базе PowerPC) и для Windows (я про сам драйвер, а не всякие там утилиты настройки)? А в пределах одной процессорной архитектуры, асм вполне переносим.


А про то, что людям может быть удобней писать на С++ и использовать ООП, чтобы как разу уменьшить трудоемкость и количество ошибок, ты как-то сразу забыл 

Добавлено через 29 секунд

Модератор придет и разделит тему