ну яrdb_devв Си и C++ даже синтаксис условных директив компилятора несколько отличается
А можно как-то увидеть чем именно несколько отличается? Чисто для поднятия уровня эрудиции.

:) ну, в ANSI C89 таки нет #if defined

rdb_devschiНикто не мешает писать на C, используя принципы ООПЭто как? Ну, с инкапсуляцией понятно, а как быть с полиморфизмом, наследованием и виртуальными методами? Писать всё ручками в соответствии с ABI C++? Это шутка такая?

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

где они еще с натяжкой применимы как must have - это вские виджеты или UI контролы, но и там - все достижимо - см. реализацию GTK+

log_hereПредполагается, что строк одинаково или почти одинаково, понятность тоже не отличается.
Преимущества на C: думаю, скорость и большая универсальность (C понимают и некоторые другие языки).
Преимущества на C++: больше всяких новинок (начиная с C++11), больше манёвров для изменений.

Кто что думает?

я в бытность купился на то, чтобы писать исключительно на C, а не на C++, ибо так завещал великий Торвальдс, да и изучать гигазы "рулеза" вроде STL/Boost откровенно не хотелось.

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

а это плохо, ибо велосипед - его будет знать и развивать ну очень ограниченное сообщество.

меня пока сдерживает только перспектива "новой парадигмы" - в собственном "STL" я в принципе ушел от понятия heap (malloc/free прикладному программисту у меня недоступны, все ловко сделано аля Java GC с поколениями и стек-контекстами), и еще пару идей

но начинающим подобное строго противопоказано.

P.S. А вот что действительно недостает в C - так это параметров по умолчанию, перегруженных функций и возможности явно скрывать поля в структурах, оставляя RTTI о размере объекта в целом.
решается это все конечно макросами и прочими _Generic, но какой ценой....

в общем без реально веских на то причин и без 10+ лет опыта подсаживаться на Pure C - не стоит

rdb_devdbpatchгде они еще с натяжкой применимы как must have - это вские виджеты или UI контролы, но и там - все достижимо - см. реализацию GTK+GTK+, это процедурное API.

и что с того? внутри лежит именно компонентная ООП модель.

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







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

rdb_devну яПруф, видимо, при передаче в интернет утратился?Какой тебе еще пруф? напиши в заголовочном файле какой-нибудь программы на Си #if defined() и попробуй компильнут на "Гнусе". Вот и весь пруф!

ну, справделивости ради - GNU C вполне себе поддерживает #if defined даже в режиме -ansi -pedantic

честно говоря уже не помню, на именно каком C компиляторе я на это наступил

rdb_devdbpatchи что с того?Ничего. Просто уточнил.
dbpatchвнутри лежит именно компонентная ООП модель.Как это реализовано, для "внешнего наблюдателя" не имеет значения.

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







все остальное это лишь визуально-синтаксический сахарок. при должном навыке на C можно писать точно такой-же, в т.ч. и по компактности в строках код. выглядеть будет непривычно, но это будет точно такой-же по возможностям ООП языкЯ в курсе, что вызов метода объекта, это вызов обычной функции с передачей в параметре this указателя на экземпляр класса, который, в большинстве случаев, содержит в качестве первого члена указатель на таблицу виртуальных методов. Собственно, указатель на экземпляр класса можно интерпретировать как указатель на указатель к массиву указателей на функции, каждая из которых в качестве первого параметра принимает указатель на экземпляр класса. Нам-то с тобой понятно, что я написал, а новичок будет долго фтыкать и курить ABI .

не будет, ибо он понятия не имеет, что это такое и зачем это ему нужно.

новичок обычно начинает с зачитывания какого Страустрап за 21 день и дальше начинает просто подражать другим.

ну яА нельзя ли раскрыть по "все остальное" к примеру про эксепшены и деструкторы, про выход из области видимости и деструкторы. Как это написать на С при должном навыке, покажите?

1) exceptions как концепция - это очень большая ошибка индустрии, ибо это лишь завуалированная форма GOTO, причем за область видимости функции. породила намного, намного больше проблем, чем решила.

я вот за многие уже десятки лет так и не понял, на кой хрен они вообще были придуманы. как способ возврата кодов ошибки - возможно, хоть и криво, а так, в большинстве случаев они лишь используются для неперехватываемого проброса наверх для генерации call-stack trace и dump. ну так последнее в C можно делать и обычным способом - backtrace и вперед.

в общем на кой нужны эти ваши Exceptions - для меня лично есть большая загадка.

а за программировать "логику" на исключениях - и это все признают, нужно руки отбивать.

кроме того, есть прицип live-to-die, "падай как можно раньше", см. PHP, Erlang и подобное - там никакие "пробросы и обработка исключений" не нужны, любое необработанное исключение априори приводит к завершению процесса и уведомлению об том клиента

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


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

iv_an_ruCEMbможете кинуть в меня камушком, но виртуальные методы - это не капец какая нужная штука, без них можно в большинстве случаев обойтись. Вот инкапсуляция - это бОльшая часть ООПы. А полиморфизм - это когда:
- у вас есть набор объектов разных классов
- все свалены в одну кучу
- и вы понятия не имеете, кто из ни кто, на тот момент когда с ними вдруг понадобилось что-то сделать.

... да это бардак какой-то! Угу, бардак. Только иногда неизбежный. Например, ваш экзешник прилинковывает к себе чужие плагины... причём с двунаправленным импортом таблиц функций... причём на операционке, которая не поддерживает двунаправленный импорт (т.е. после работы системного линковщика функции DLL могут быть вызваны из экзешника, но не наоборот). И внезапно двум плагинам хочется использовать функции _друг_друга_, да ещё подгрузить свои карманные DLL-ки.

пример неудачный.

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

мы говорим больше про идеализированного коня в вакууме - пишем с нуля, выбрасываем все ненужное и лишнее

iv_an_rudbpatchлично меня подобная проблема (освобождение ресурсов) вообще не парит - я давно пришел к пониманию "контекста" - к примеру времени жизни веб запроса.Десяток взаимодействий с дефицитными "долгоживущими" разделяемыми ресурсами, использующими что-то вроде AddRef() и Release(), которые в силу дефицитности не могут ждать даже до конца вот этого коротенького "контекста" --- и вот тут-то вы и начнёте мечтать о плюсах :)

пример сугубо гипотетический, и тем самым неактуальный.

из моей практики были примеры "долгоживущих" - в тех же самых контекстах стоит задача интеграции со сторонними вебсервисами и прочими базами данных,
условно 100500 клиентских коннекшинов одномоментно делают запросы, а количество соединений к внешней базе данных ограничено (не более 10 за раз, к примеру).

и?

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