Иными словами, в стиле структурного программирования, но с применением некоторых полезных, на мой взгляд, возможностей С++ ("синтаксического сахара"):

• namespace — Имена констант/типов/функций обычно снабжаются приставками для предотвращения конфликта имен и/или обозначения принадлежности к кругу решаемых задач. Namespace делает это необязательным. Есть возможность чаще использовать короткие имена, и лишь в отдельных местах - полное имя (с квалификатором "::"). Определенные через #define целые константы можно заменить на enum, вещественные/строковые - на static const переменные, макросы - на static inline функции.
• Перегрузка функций — Не требуется несколько функций с именами типа func(...) и func_ext(..., дополнительные параметры) и т.п. Сокращение количества имен функций, лучшая читаемость кода.
• Параметры функций по умолчанию — Улучшение читаемости кода. Например, "стандартный" вызов функции проще и писать, и отличать от вызова с особыми условиями. Что-то типа show_mode(mode) и show_mode(mode, "Error") вместо show_mode(mode, NULL) и show_mode(mode, "Error")...
• Классы — Без фанатизма. Часто есть некая структура (struct) и несколько функций для ее обработки, которым через параметр передается указатель на структуру. Класс делает тоже самое (неявно), но позволяет лучше логически связать стуктуру и функции. Плюс опять таки пространство имен.

Вот такие есть мысли о применении C++ в своих проектах в ближайшем будущем.

С другой стороны:

• Много слышал о глубокой любви Линуса Торвальдса к С++. Дядечка этот умный и считаться с его мнением стоит
• Некоторые полагают, что крайне опасно открывать двери к проекту для сферического С++ программиста. Честно говоря, такие посты как это или это самого наталкивают на такие мысли (ну или я чего-то не понимаю).

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

Хотелось бы услышать мнение других. Приглашаю к дискуссии.

C++ никогда не порывал с духом C. Т.е. можно писать на C++, используя только сишные конструкции, а от C++ используя лишь отдельные "вольности".

"Вольностей" хватает в gcc --std=gnu99
Единственное, чего не хватает, чтобы остаться в чистом как слеза Си, - это шаблонов.
Правда, препроцессором вручную подобие темплейта можно изобразить за счет __builtin_typeof()

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

Бзусловно, Вы правы, Xenia. Собственно я о том же и говорил. Вопрос в другом.
Если есть проект, написанный фактически на Си, но с "улучшениями" С++ (описанными выше), призванными улучшить ясность, читаемость кода.
Нет ли опасности, что на самом деле другие разработчики, которым придется далее подерживать проект, не оценят этих стараний. Вдруг все будет наоборот — сторонник чистого Си будет плеваться и называть автора извращенцем, а приверженец С++ презрительно кривиться над "недопрограммой", потому что в ней не применяется ООП, не используется STL (или используется только малая часть) и т.п.?

STL нужно использовать когда знаете, как ее правильно использовать.
А пока надо писать так, как умеете, чтобы получилось хорошо и Вы понимали каждую строчку кода.
С++ поддерживает ООП, но не обязывает к нему. Мне кажется, никаких проблем с приверженцами С++ не должно быть.
Но стоит потратить некоторое время на изучение стандартной библиотеки C++. Будет из чего выбирать.

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

и ышо один момент. ООП - это к языку не имеет ни какого отношения. т.е. сначала идут ООА и ООП а уж потом выбор языка, в частности си плас плас (если о нём идёт речь). Но можно писать и на _не_ объектных языках. Кто запрещает то???

так, что в Вашем вопросе больше просматривается не совсем глубокое понимание вопроса касаемого ОО вещей.

Боюсь, что Вы меня не совсем правильно поняли

Не противопоставляю. Просто есть известное мнение одного известного человека о С++. Отсюда возникает мысль, что среди чистых С-программистов найдется немало людей, разделяющих его. Да и 10 страниц текста в википедии о "критике C++" только подкрепляют опасения...
Нигде не утверждал обратного. Я знаю, что ООП, равно как и структурное или обобщенное программирование — это парадигмы, которые язык позволяет использовать, но не принуждает к этому.
Вовсе не пытался изображать глубокое понимание ООП. Просто возникла мысль, что программисты на С++ стараются использовать ООП (и скорее всего не безосновательно), и поэтому будут косо смотреть на проект, выполненный на С++ но в рамках структурного программирования.

Итого, мне просто хотелось услышать мнения о проекте на С++, выполненном только в "структурном стиле" с использованием некоторых синтаксических возможностей плюсов (namespace, перегрузка функций, классы, возможно местами template-ы):

1. От программистов на С — как бы они отнеслись к подобному проекту?
2. От программистов на С++ — как бы они отнеслись к подобному проекту?

Вот и все.

з.ы. Неоднократно читал вот эту тему, не хотелось бы, чтобы дискуссия скатилась в таком же направлении (ООП vs С и проч. бессмыслица).

Ну это вы немножко перегнули. Надо выбирать язык, поддерживающий выбранный ранее стиль программирования. Писать- то на си можно, но на С++, Java и Python оно гораздо естественнее выглядит (Других языков не изучал).

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

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


Имхо:
1) +
2) +

Не стоит. Его мнения есть смысл учитывать в применении к проекту "Linux kernel". Он и модульность не любит, без которой ничерта не протестируешь - bs для коммерции.
В объектном стиле в том же Linux кое-что написано [1], [2].

складывается такое очучение, что Вы не так трактуете ООП.
Данная абривиатура расшифровывается как Объектно Ориентированное Проектирование и _никак_ иначе!!!

Сначала идёт ООА (Анализ) и ООП (проектирование) А уж потом выбор языка(инструмента) и ваяние(программирование).

Ну и опираясь на этот всем известный фундамент - объясните дураку как ООП зависит от языка???




После грамотного ООА и ООП Вы можете писать хоть на азме. Фиолетово. Да не будет кучи плюшек при "изложении лаконичности мысли", но заметьте - при этом Объектно Ориентированное Проектирование _не_ пострадает!!!

Лично сам, создавая программки на азме, следую ОО подходам в построении программ. Программы выглядят не монолитным куском, а структурированные по объектам из бизнес логики. И если некая сущность не может "тявкать" по изначальным бизнес рамкам - то она этого никогда и не будет делать. Т.е. язык вторичен, в случае правильного подхода к процессу создания программного продукта.

ну собственно ничего нового я не сказал, усё доходчиво описано у старика Буча...



отвечая на ваш вопрос, о "структурном стиле". дело в том, что объектный подход - есть собственно единственно правильным. или скажем по другому. при решении задач посредство ОО метода мы имеем _более_статичную_модель_ = как следствие имеем меньше переделок = как следствие имеем меньше кода = как следствие имеем меньше человеко часов... И заметьте - это только один(или сколько там образовалось?) плюс(ов)!!! а их ышо куча и маленькая тележечка!!! про упрощение сапота, пониженного уровня вхождению в тему, гибкость, и т.д. и т.п. можно долго говорить... и это только эта метОда даёт. я бы с удовольствием познакомился с другой методологией - но пока нетю...

Такие безаппеляционные заявления то ли молодость выдают, то ли.. Вот прямо таки единственно ? И жизнь обязана быть углеродной и требовать воды ?

Ужас, ужас, ужас..
Namesace и default parameters для улучшения читаемости?
что такое "улучшение читаемости"?
Меньше букв, красивее названия?
Не перевариваю namespace.
Ну будет вначале файла using;
и что, помог неймспейс? Как понять куда функция относится, особенно если 2 одинаковые
из разных неймспесов?
А дифоулт параметерс?
Мне каждый раз надо идти в хедер проверять что там по дифоулту передается?

Никогда не обращал внимания че там Линус говорит, но тут он 100% в точку.
Чем меньше С++ увлекатся, тем лучше.
Переболеть им надо, но это не панацея, 70% из его фенечек лучше непользовать.
Он сейчас между Java и C.
Ни там ни там толком не заменяет.

Если можно авойднуть С, то его лучше авойднуть.
Особенно в микроконтроллерах.
Да, не в последнюю очередь изза меньшей прозрачности и предсказуемости
как код будет скомпилирован.

угумс. в душе все 18 мну. в ванной итого меньше

ну а если по Вашей реплики - кмк я дальше разжевал полёт мысли. или Вы только первое предложение увидели? ик...

А я дальше и читать не стал, после слов "есть собственно единственно правильным" - это от бабки во дворе, от попа можно слышать, но не от инженера

Что касается Линуса, я думаю, он вполне обоснованно опасается толпы неграмотных кодеров, не способных правильно писать на C++, а также плохой совместимости между реализациями C++, что грозит адскими проблемами при портировании ядра. Но это всё не наш случай. Автор второго поста(из Интела) вроде бы вообще ничего, кроме GUI, не писал, но при этом требует использовать GUI паттерны для всех программ без исключения. И это тоже не наш случай. Я использовал в микроконтроллерах именно "С с классами", и остался вполне доволен - это удобнее простого С. А ещё в C++ стандартизованы инлайн функции, и шаблоны тоже можно использовать(без фанатизма). Причём на шаблонах можно сделать эмбеддерский аналог STL для контейнеров, без аллокаторов, с хранением узла прямо в структуре объекта, который кладётся в контейнер. Это в некоторой степени даже удобнее традиционного STL.

Отладка STL по шагам еще то удовольствие. И IAR совсем плохо воспринимает шаблоны. Тоже не наш случай.
А "С с классами" это просто "модульный C".

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

Там что, реализация каждую неделю, как Виндоус апдейт, а не раз в 10 лет?

И без шаблонов С++ предоставляет достаточно вкусных плюшек, чтобы использовать именно его. Причём ТС и не собирался пользоваться шаблонами.
Я имел в виду худшую совместимость между различными компиляторами C++, чем между компиляторами C. Интересно, а ядро Линукса вообще можно собрать не gcc?

Именно "плюшек". Просто ввели в C++ элемент развлечения. Типа попробуй сделать одно и тоже десятком способов.

Но можно развлекаться и по другому. Скажем писать одно и то же на Pascal, C, Java, JavaScript, Python и т.д.
И восхищаться красотой редуцированного синтаксиса. Скажем применять из всех конструкций только цикл в стиле for.

И уже иного раз говорили. Линукс собирается не GCC, а тучей вспомогательных тулсов включая GCC. А компилить все исходники ядра может и RealView от ARM.

Уже пересобрали с момощью Clang/LLVM, причем не только ядро, а целые дистрибутивы.