статья немного интересная, но написана человеком, который слабо представляет БИНАРНУЮ реализацию виртуальных и невиртуальных ф-ий. Я уже молчу об inline ф-иях.

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

статья писал:Если автор родительского класса в языке Си++ не предвидит, что класс-потомок захочет переопределить функцию, то он не сможет сделать ее и полиморфической. В этом заключается наиболее серьезный порок Си++, поскольку снижается гибкость программных компонентов, а следовательно, и способность создавать адаптируемые и расширяемые библиотеки.
Смешное высказывание. В Java, напр, по-умолчанию все ф-ии являются виртуальными. Никто не мешает добавлять спецификатор virtual в С++, точно так же, как никто не мешает ставить final в Java. Т.е. мы имеем возможность выбирать м/у истинным ООП полиморфизмом, и обычным, эффективным вызовом ф-ии. (известно, что вызов полиморфной ф-ии гораздо дороже чем вызов обыкновенной)

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

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

С++ имеет защиту от бездумной перегрузки сигнатур ф-й:
если в классе потомке какая-то ф-я была перегружена другой сигнатурой, то одноименные ф-ии базового класса становятся недоступны. :)
Т.е. - хочешь перегружать сигнатуры - делай это. Может это именно так и надо проектировщику! Но путаницы и неверного толкования семантики не наступит, т.к. ф-ии базового класса будут скрыты. Чтобы получить к ним доступ, мы должны переопределить ВСЕ ф-ии с таким же именем в классе-потомке, т.к. "пропустить" через себя все сигнатуры. Это, на мой взгляд, нехило оберегает от случайных ошибок, оставляя, тем не менее пространство для выбора оптимальных решений по-месту.

далее автор немного увлекается, и явно не готов ответить на вопрос: а ЗАЧЕМ?
автор писал:Си++ также не защищает класс B от других изменений, вносимых в систему. Предположим, что нам требуется создать такой класс C, у которого процедура nonvirt должна быть виртуальной.
Должны быть веские причины, чтобы в системе классов, где данная ф-ия изначально невиртуальна, вдруг сделать ее виртуальной. Так вот вопрос звучит так: зачем определять виртуальную ф-ию с тем же именем , ведь изменения невиртуальной ф-ии на виртуальную - это неслабое изменение с точки зрения системы классов, т.е. однозначно, предполагаемое поведение ф-ии поменяется. Зачем , в этом случае, делать новую ф-ию с тем же именем/сигнатурой??? Новое поведение --> новая ф-ия. (вполне было бы логично)

продолжение следует...

1. Продолжения не будет. :))
автор трижды , возвращается к одному и тому же и ходит по кругу, я не испытываю желания комментировать одно и то же трижды!

2 Lepsik

а ведь, по большому счету плевать, КТО ИМЕННО ввел term Object-Oriented.

в это понятие Alan Kay не вложил даже полиморфизм , в свое время. А указанная статья ругает именно способ поддержки полиморфизма . И на основании этого "опускает" С++, с т.з. объектности... умора!!!

Алан ввел это понятие, но мир это понятие юзает по другому и плюет на Алана и его любимый Small Talk.
закрытая система, панимашь... сообщения, панимашь... а как насчет защиты? private/protected? а? - можно ЛЮБОЙ метод вызвать, если он есть (отсюда и "тесты - вперед") ... а эффективности вызова? тут Алан, конечно, поторопился, что не имел ввиду С++
Ибо Small Talk вообще не соответствует понятию "Object Oriented" в его современном понимании, хотя аппологеты и утверждают, что только Small Talk по-настоящему-то и ориентирован.
да... весь мир заблудился в 3-х соснах... путаница терминов...

ну, если он выртуал, то переносить его никуда не стоит :) - грохнется все. надо по-месту менять public/protected/private.

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

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

вдогонку, что мы подразумеваем под словом защита ?

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

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

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

про то и речь, тулзов хватает...

т.е. если не рассматривать "механический" способ взлома предоставляемой языком защиты, то С++ неплох.

Правда, надо признать, что C# и Java - надежней. :)

в С++ есть большая дыра - она же преимущество. Ты можешь любой адрес рассматривать как некий вменяемый объект, путем приведения типа в стиле С.
На Java и .Net - не можешь.

Предпоследнее предложение в предыдущем посте мне очень нравиться.