В C++ единицей инкапсуляции является класс

[@BuriK666]

Переименуйте методы, очень тяжело читать всякие f,g,h
может стоит назвать protected_method, private_method, public_method или еще как.

[@oleg1977]

Да, я исправлю, но никак не придумаю, как лучше это сделать:
_method мне не нравится, потому что в C++ нет понятия метода
Варианты:
_member или _mem
_function или _fun или _fn или _f
просто _

Пока никак не остановлюсь на чем-то. В каждом мне видится какой-то недостаток

[@cblp]

Почему нет понятия? Функция, определённая в классе — чем не понятие? Вы хотели сказать, что нет строгого термина? Ну, понятия и не обязаны быть строгими.

[@TheHorse]

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

unit Unit2;

interface

type
  TSomeClass = Class
  private
    x : integer;
  end;

var
  foo : TSomeClass;

implementation

initialization
  foo := TSomeClass.Create;
  foo.x := 10;
  foo.free;
end.

Delphi 7 спокойно компилирует этот код, и считает что в нем нет ошибок.

[@jack128]

до появления strict private — модуль. в тех версиях где есть strict private — аналогично плюсам

[@TheHorse]

Говоря о том, что было до strict private, есть 2 нюанса, которые говорят о том, что все-таки не модуль является единицей инкапсуляции:
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
2. Синтаксически и семантически свойства и методы инкапсулируются в класс.

[@jack128]

есть 2 нюанса, которые говорят о том, что все-таки не модуль является единицей инкапсуляции:
1. Приватный метод класса можно вызвать из другого модуля (например, посредством перегрузки (override) метода с другой областью видимости)
это говорит только о том, что класс не инкапсулирует свои private члены. Модуль же инкапсулирует все, что находится под implementation. Помести туда класс и никто извне модуля не сможет к нему доступ иметь.

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

[@GooRoo]

Как говорится… И чо?

[@oleg1977]

Ваш вопрос «И чо?» задают новички C++ компилятору, когда последний пишет «Base::f() is protected» на строку (3), потому что новички думают о protected как о том, что написано в 15.3 у Строуструпа (см. пост)

[@GooRoo]

Приведите пример, когда новичку в принципе может понадобиться так писать. Доступ к private/protected членам объекта того же типа дан был не для того.

[@oleg1977]

Ну, например, я видел такой код, написанный опытным программистом на C, новичком C++:

class Base {
 friend class Derived;
 protected:
 Base* Create();
};

class Derived : public Base {
public:
 Base* CreateBase() {
  Base* b = new Derived;
  return b->Create();
 }
};

Собственно, исправляя этот код я и написал пост.

Очевидно, что он просто ошибся в типе b: нужно было написать просто Derived* b = new Derived; (кстати,
такая ошибка произошла тоже по понятным причинам, но это уже за рамками поста)

Дальше он не понял, почему компилятор ругался на вызов b->Create() и попросту добавил Derived в друзья Base

[@GooRoo]

Спагетти какое-то, ей-богу. Новичкам я бы вообще не разрешал использовать protected.

[@Qualab]

Пусть лучше дальше пишет на чистом Си. Вы его ещё спецификациями шаблонов напугайте и RTTI.

[@oleg1977]

шаблоны и касты кроме C-style в этом проекте запрещены

[@gribozavr]

А когда вы пишете на Си то вы заставляете разработчиков называть все переменные только идентификаторами с чётным числом символов? Откуда это необоснованное желание писать на каком-то вымышленном подмножестве языка?

[@oleg1977]

я никого не заставляю ни в этом проекте, ни в других. о данных конкретных запретах не высказываю никакой своей точки зрения. но вообще-то code style и projects restrictions — это обычная практика и тоже, фактически, приводит к формированию подмножеств языков. например, запрет на использование вещественных чисел может быть вполне обоснован для некоторых проектов. так что само по себе программирование на подмножестве — это не плохо.

[@gribozavr]

Шаблоны запрещены — прощай стандартная библиотека? C++-style casts запрещены, так пусть у нас везде будет reinterpret_cast? Плохо когда ограничения не имеют смысла.

[@oleg1977]

stl тоже запрещена. reinterpret_cast тоже запрещен. еще раз говорю, что это не мое решение и я его не комментирую

[@gribozavr]

C-style cast сильнее чем reinterpret_cast, поэтому я и говорю что ограничение бессмысленное.

[@oleg1977]

Я бы хотел уточнить. Пример кода не прямо скопирован из проекта, а воссоздан аналог, и в оригинале семантика не создания — Create(), а заполения класса Base из файла, при этом Derived — парсит файл, а Base — загружает в объект распарсеные значения. Так что если возникло ощущение, что очень сложно происходит создание, что код перенасыщен спагетти — то это уже моя вина: я написал первое пришедшее на ум имя функции Create(), потому что не думал об имени, а думал о том, какая функция какую вызывает. Здесь сразу несколько слоев ошибок. Самое главное, что между Base и Derived не должно быть наследования: должна быть композиция. Соответственно, нечего делать protected в классе Base. Но я хотел заострить внимание на проблемах более низкоуровневых, которые появляются если приведенную архитектуру считать данностью. Плохая архитектура — яма в которой человек сидит, у него три пути: выйти из ямы, остаться на месте и закопаться еще глубже. Первый путь не возможен по не зависящим от него причинам, скажем так, запрещен. Из двух оставшихся он выбирает последний, потому что по не знанию инструмента (языка), фактически делает движения вслепую. А если бы знал — мог бы остаться, не закапываясь глубже :)

[@Qualab]

Очередной теоретик программирования. Может уже программы будем писать эффективно, а не «правильно». Хотя топик создать — не мешки ворочать. Проще всего сослаться на некий авторитет после прочтения некой книги, куда проще чем создать годный продукт, который всем нужен.

[@oleg1977]

одно другому не мешает. а иногда даже наоборот

[@Qualab]

Желание сделать всегда и везде код «правильно» гарантированно не помешает наваять архитектурного монстра, вместо того чтобы сделать всё просто и эффективно.

[@GooRoo]

С опытом приходит понимание, что «эффективно» и «правильно» — это одно и то же.

[@Qualab]

Дело в том, что эффективно и правильно — это разные понятия, а «эффективно» и «правильно» — это по сути одинаково неэффективно и неправильно. Понимание правильного действительно приходит с опытом, и приводить в качестве аргумента книгу не есть хорошо, её даже понять прочитав можно сильно по-разному в зависимости от зрелости и понимания.
Данный топик поможет вам осознать, что класс — единица инкапсуляции. Замечательно. Где профит?

[@gribozavr]

> Строка (4) демонстрирует, что вторая часть утверждения о единице инкапсуляции обходится проще, чем первая

Эта строка демонстрирует undefined behavior, а не то что вы написали.

[@oleg1977]

То, что это UB никак не мешает тому, что приведенная конструкция проще, чем пример Герба Саттера в «Exceptional C++ Style» решении № 3 задачи 15. Там тоже UB.

[@Chaos_Optima]

> Строка (4) демонстрирует, что вторая часть утверждения о единице инкапсуляции обходится проще, чем первая

Эта строка демонстрирует что автору надо руки оторвать. Лучше бы запретил даункасты вместо шаблонов, а если и делаешь даункаст то делай правильно, посредством динамик каста.

[@oleg1977]

Это код не из проекта, а демонстрационный, приведен с той же целью, что упомянутый выше из «Exceptional C++ Style». Понятно, что так писать не нужно