socimedЗаточить - это не в значении обработать напильником, а в значении "приспособить под себя".

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

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

Таким образом в приведенной вами метафоре две корявости, так сказать, в одном флаконе - паразитный каламбур и исключительно неудачный подбор понятий.

Подводя итог, могу сказать, что:
Вы игнорируете или не понимаете часть аргументов

Часть аргументов отвергаете (см ранее ссылку на работу Беклемишева о женской логике)

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

Таким образом обсуждать по существу с вами невозможно.

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

Упоминаемая двойная корявость в метафоре "заточки молотка"

Предложили сравнить быстродействие функций не описав реализацию

В ответ на тезис о применимости ООП для практической задачи по документации кода привели ссылку на инструмент который во-первых, сам по себе доказывает практичность задачи, во-вторых, написан с использованием ООП

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

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

socimedПишется на том-же С, модели описываются по упрощенным BNF (XML семантически подобным). Цели простые - обобщенное программирование (программы пишут другие программы).
Т.е. подробности реализации убираются с целью оставить только DSL модели.


То есть фактически вы используете XML написанный ручками в качестве синтаксиса для своего DSL? И XML разбираете и преобразовываете в C при помощи того же C?

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


Какого рода наследование?

Пример подобного есть тут


Посмотрю.

А соглашаться со мной не надо, в 99.9999% это пагубно для неокрепших умов.

Если вы не приводите своих аргументов и игнорируете мои - то для виду можно согласиться. Вот видите - я согласился и мы продвинулись в интересный оффтопик.

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

А VMT? А инкапсуляция?

AddxF#,
тут сравнивается просто само наличие объектов.
VMT без виртуальных методов не существует,
такой возможности в не ОО языках нет вообще.


В не ОО языках во-первых, пишут код подставляя реализацию статически (типа, если мы точно знаем. что сюда может придти только triangle то вызываем triangle_draw).

Во-вторых, можно использовать if или case (см оконные процедуры в виндах)

В-третьих, можно сделать VMT ручками и управлять самостоятельно.

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


Про возможности никто не спорит - спор о том, есть потери или нет.

Для не виртуальных методов VMT не используется.
Про инкапсуляцию поясните.

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

softwarerДля этого как минимум придумали свойства, в которых как раз и можно безболезненно подменить поле методом.

С сохранением бинарной совместимости? Сомневаюсь что это есть в C++ - не можете привести ссылку?

softwarerА мир у нас ограничен C++?

Я отвечал на "ООП по типу С++ не требует накладных расходов."