class A final {};

Ключевое слово final. В QtCreator, если что, корректно подсвечено с версии 2.6, в gcc реализован с 4.7, в clang с 3.0 вроде бы.

class A {} ;
class B final : public A {};

Есть способ реализовать аналог final в старом стандарте.

при чем тут java в метках. Ответ на твой вопрос гуглится на раз.

Следует только сказать, что final есть только в С++11.

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

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

я еще могу понять шаровары проприетарщину и суровые 90е

Неужели если сделать «#define final», то оно спокойно не унаследуется от какого угодно класса?

Как минимум чтобы гарантировать определенное поведение методов. Например если класс Math объявлен с атрибутом final, то вызов Math.sin(x) гарантирует, что будет вычисляться именно синус, а не что-нибудь еще.

Как минимум чтобы гарантировать определенное поведение методов. Например если класс Math объявлен с атрибутом final, то вызов Math.sin(x) гарантирует, что будет вычисляться именно синус, а не что-нибудь еще.

для этого достаточно не делать метод виртуальным

Хмм... привычка объявлять методы виртуальными )

ой, да ладно тебе. В жабе финализация обходится через sun.misc.Unsafe как два пальца обоссать. Так что нифига твоё final не гарантирует.

Гарантирует. Ибо 95% кодеров на Java дальше java.* и javax.* не ходят.

это как зебра на дороге гарантирует, что по ней можно эту самую дорогу безопасно перейти. Ага, как же.

sun.misc.Unsafe

Приватное апи, использующие — ссзб.

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

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

Любые модификаторы доступа влияют только на семантику во время разработки.

да, конечно. Представь, твоя компания закупила для тебя проприетарную библиотеку для разработки на жабе, но вот же незадача: классы там финализированы, а по лицензии ты не имеешь права менять сырцы если вообще есть к ним доступ. Что в итоге? Это кстати довольно распространённый случай в этом вашем ынтерпрайз-кодинге (про сырцы и лицензию, не про final).

Используй паттерн Адаптер, он тебе поможет.

я кажется уже говорил про геморрой, не? Впрочем и пофиг, жабокодиры должны страдать!

я вот не понимаю, например, зачем эта финализация вообще?

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

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

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

для удобство проектирования классов, чтобы не писать //TODO bla-bla
Ну ты понял

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

man принцип подстановки Лисков

Следует только сказать, что final есть только в С++11.

Есть универсальный аналог:

/*final*/ class A {};

что ты пишешь такого что нужно финализировать и закрывать в клиентском коде

Например, класс без виртуального деструктора

Комментарий не читай @ супертип расширяй.

лишняя и бесполезная сущность

Что отлично вписывает её в С++.

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

оно бы заработало если бы он нагородил с нефинализированным?

Если по каким-либо архитектурным причинам наследоваться от класса нельзя и он финализирован, то конкретно такой вариант неправильного использования реализовать не получится в принципе. Для чего по твоему в некоторых классах запрещают копирование или явное создание объектов? Представь например std::unique_ptr с разрешенными конструктором копирования и копирующим оператором присваивания. А теперь представь еще отсутствие документации к нему. Что будет если ты сделаешь копию этого объекта? Как быстро ты поймешь как с ним правильно работать?

читал наискосок

ваши аргументы пока для меня высосаны из пальца

Взаимоисключающие параграфы.

тред не читал. виртуальное наследование уже упоминали?

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

причём тут 90е? часто встречаются классы, которые в принципе не предназначены для наследования. Почему-бы не написать final, что-бы всем было понятно (и компилятору в т.ч., для особо упёртых).

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

это тебя надо бить головой об стол, т.к. ты пишешь такие классы, от которых приходится что-то там наследовать, и переопределять твои методы, ибо иначе они не работают как надо.

лол, очевидно же

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

лол, очевидно же

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

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

Если на дороге виновен всегда тот кто едет сзади, в программировании виновен всегда тот кто пишет код. Только сел писать новый код - всё, уже виноват.

никто ниодного внятного аргумента не доставил, кроме «я уберегу будущие поколения», да кто ваш код дописывать будет, а когда будет первое что сделает — уберет вашу финалацию. я говорю это как практик. да, для генеральных штук каких-то, библиотек, но не для того что пишет 99.99% наших коллег