Сообщение Re[10]: понимание ООП Алана Кея от 24.03.2023 12:34
Изменено 24.03.2023 13:46 vdimas
Re[10]: понимание ООП Алана Кея
Здравствуйте, Sinclair, Вы писали:
S>Ну так для того, чтобы "мой" код корректно работал, мне нужны гарантии не только того, что я не изменяю объект, но и что никто другой его тоже не изменяет.
Вдогонку, паттер Wrapper (Decorator) никто не отменял.
Оберни нужный тип по-значению (абстрации в С++ бесплатны, угу), опиши оборачиваемое значение как константное поле типа (т.е. инициализируемое только в конструкторе), опиши соотв. делегирующие const-методы.
Конструктор объяви перемещающим, чтобы гарантировать отсутствие немутабельных внешних ссылок на владеемые тобой данные.
Сделать это можно однократно в несколько строк в шаблонном виде, что для типа-ключа, что для словаря целиком.
Такая система ограничений будет работать с любым объектом, удовлетворяющим публичному интерфейсу std::map (их даже изкаробки идёт уже несколько).
Свой шаблонный код опиши уже в концептах и будет тебе железобетонная уверенность. ))
При том, что всё еще будет сохранятся доступность эффективного сценария, когда можно будет относительно дешево набить мутабельный словарь значениями и затем переместить сформированные данные в "железобетонный" иммутабельный тип без потери эффективности как на таком копировании (там пара полей-указателей копируются), так и в работе (отсутствуют лишние уровни косвенности).
Если тебе интересно закрыть эту тему раз и навсегда — распишу весь код целиком.
S>Ну так для того, чтобы "мой" код корректно работал, мне нужны гарантии не только того, что я не изменяю объект, но и что никто другой его тоже не изменяет.
Вдогонку, паттер Wrapper (Decorator) никто не отменял.
Оберни нужный тип по-значению (абстрации в С++ бесплатны, угу), опиши оборачиваемое значение как константное поле типа (т.е. инициализируемое только в конструкторе), опиши соотв. делегирующие const-методы.
Конструктор объяви перемещающим, чтобы гарантировать отсутствие немутабельных внешних ссылок на владеемые тобой данные.
Сделать это можно однократно в несколько строк в шаблонном виде, что для типа-ключа, что для словаря целиком.
Такая система ограничений будет работать с любым объектом, удовлетворяющим публичному интерфейсу std::map (их даже изкаробки идёт уже несколько).
Свой шаблонный код опиши уже в концептах и будет тебе железобетонная уверенность. ))
При том, что всё еще будет сохранятся доступность эффективного сценария, когда можно будет относительно дешево набить мутабельный словарь значениями и затем переместить сформированные данные в "железобетонный" иммутабельный тип без потери эффективности как на таком копировании (там пара полей-указателей копируются), так и в работе (отсутствуют лишние уровни косвенности).
Если тебе интересно закрыть эту тему раз и навсегда — распишу весь код целиком.
Re[10]: понимание ООП Алана Кея
Здравствуйте, Sinclair, Вы писали:
S>Ну так для того, чтобы "мой" код корректно работал, мне нужны гарантии не только того, что я не изменяю объект, но и что никто другой его тоже не изменяет.
Вдогонку, паттер Wrapper (Decorator) никто не отменял.
Оберни нужный тип по-значению (абстракции в С++ бесплатны, угу), опиши оборачиваемое значение как константное поле типа (т.е. инициализируемое только в конструкторе), опиши соотв. делегирующие const-методы.
Конструктор объяви перемещающим, чтобы гарантировать отсутствие немутабельных внешних ссылок на владеемые тобой данные.
Сделать это можно однократно в несколько строк в шаблонном виде, что для типа-ключа, что для словаря целиком.
Такая система ограничений будет работать с любым объектом, удовлетворяющим публичному интерфейсу std::map (их даже изкаробки идёт уже несколько).
Свой шаблонный код опиши уже в концептах и будет тебе железобетонная уверенность. ))
При том, что всё еще будет сохранятся доступность эффективного сценария, когда можно будет относительно дешево набить мутабельный словарь значениями и затем переместить сформированные данные в "железобетонный" иммутабельный тип без потери эффективности как на таком копировании (там пара полей-указателей копируются), так и в работе (отсутствуют лишние уровни косвенности).
Если тебе интересно закрыть эту тему раз и навсегда — распишу весь код целиком.
S>Ну так для того, чтобы "мой" код корректно работал, мне нужны гарантии не только того, что я не изменяю объект, но и что никто другой его тоже не изменяет.
Вдогонку, паттер Wrapper (Decorator) никто не отменял.
Оберни нужный тип по-значению (абстракции в С++ бесплатны, угу), опиши оборачиваемое значение как константное поле типа (т.е. инициализируемое только в конструкторе), опиши соотв. делегирующие const-методы.
Конструктор объяви перемещающим, чтобы гарантировать отсутствие немутабельных внешних ссылок на владеемые тобой данные.
Сделать это можно однократно в несколько строк в шаблонном виде, что для типа-ключа, что для словаря целиком.
Такая система ограничений будет работать с любым объектом, удовлетворяющим публичному интерфейсу std::map (их даже изкаробки идёт уже несколько).
Свой шаблонный код опиши уже в концептах и будет тебе железобетонная уверенность. ))
При том, что всё еще будет сохранятся доступность эффективного сценария, когда можно будет относительно дешево набить мутабельный словарь значениями и затем переместить сформированные данные в "железобетонный" иммутабельный тип без потери эффективности как на таком копировании (там пара полей-указателей копируются), так и в работе (отсутствуют лишние уровни косвенности).
Если тебе интересно закрыть эту тему раз и навсегда — распишу весь код целиком.