GSoap и современный C++

так ладно

пусть там вместо присваивания вызов функции

ff(xx)

тогда ошибка???

Да, разумеется. Ты пытаешься использовать перемещённый объект.

https://www.onecompile.com/rust-online-compiler

Ты пытаешься использовать перемещённый объект.

он не перемещенный. допустим условие никогда не случается.

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

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

А главное для чего все это? Чтобы избежать сборки мусора? Да просто сделайте сборщик и закройте вопрос. Все так делают.

Не понимаю, чего ты хочешь? В посоветованной мною книге O’Reilly прямо пишут, что у языка есть ограничения. Он далеко не любой код жует - в этом его фишка. С другой стороны, есть предположение, что фишек раста все же хватит для решения многих, очень многих задач.

А ты сейчас желаешь rust снова превратить в С++. Нет, так не пойдет. От этого и уходили специально

Использую свю подсистему управления динамическими переменными и объектов. И non problem.

Не понимаю, чего ты хочешь?

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

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

например красиво проверить этот признак украденности(который будет нужен) и использовать другую переменную, не украденную. а почему нет?

он не перемещенный. допустим условие никогда не случается.

Тогда ты наговнокодил. Исправляй.

А вот если перемещение всё-таки случилось, то ты используешь перемещённый объект. Делать так не надо.

А главное для чего все это? Чтобы избежать сборки мусора? Да просто сделайте сборщик и закройте вопрос.

Это просто формализация тех же правил, что есть в C++. Просто в плюсах компилятор этого не проверяет и программист вынужден сам за этим следить. Да в плюсах есть чуть больше свободы действий, например в каких-то ситуациях по состоянию объекта можно определять, был ли он перемещён или нет. Но на деле это плохой дизайн кода и лучше сделать нормально. Я пока не видел ситуаций, когда растовый borrow checker заставляет писать код хуже, чем он мог бы быть без него. Наоборот, он подталкивает не писать плохой код.

Впрочем, вполне возможно, что такие ситуации есть, я растом не особо много пользуюсь.

то ты используешь перемещённый объект. Делать так не надо.

дай возможность определить - захвачен ли обьект в чужое владение(это ведь о нем разговор? а не о перемещении) и отойди.

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

дай возможность определить - захвачен ли обьект в чужое владение(это ведь о нем разговор? а не о перемещении) и отойди.

Программист сам разберётся - это философия сишки.

Философия раста - программист должен доказать, что его код корректен по памяти (и по гонкам).

Не нравится такая философия - не пользуйся растом. Пиши на плюсах и продолжай жаловаться, что мувами, исключениями, raii и прочим очень опасно пользоваться. Никто не возражает.
Лично мне философия раста нравится гораздо больше философии сишки. И хорошо, что плюсы по-тихоньку к ней приближаются. Плохо, что медленно.

Философия раста - программист должен доказать, что его код корректен по памяти (и по гонкам).

со сборщиком мусора ты вообще не должен ничего доказывать. код по «использованию памяти» будет корректен всегда.

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

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

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

и кто победит? я знаю кто, но не скажу.

Тогда ты потеряешь в оптимизации перемещения. Как я писал выше, перемещение в rust - это вызов одной функции memmove и ничего больше. Просто заголовок объекта копируется из одной области памяти в другую. Никаких аллокаций. Никаких деструкторов (в rust это называется Drop)

Ты сейчас просто борешься с ветряными мельницами. Мне кажется, что у тебя пока искаженное представление о языке rust (и да, не надо возращать тем же - вот с С++ у многих растоманов опыт как раз есть)

Кстати, еще вспомнил для затравки. Вот, есть умные указатели std::shared_ptr в C++. В раст однопоточный аналог называется Rc.

Так вот, при создании умной ссылки в rust будет ровно одна аллокация (не считая тех, что создает сам объект внутри себя). В аналогичной ситуации для C++ будет две аллокации (аллокация на объект, аллокация на внутреннюю ячейку памяти внутри std::shared_ptr).

То есть, в rust - 1 аллокация; в С++ - 2 аллокации.

Вот теперь живи с этим!

То есть, в rust - 1 аллокация; в С++ - 2 аллокации.

тююю. нашел чем удивить. в с++ это назвается std::make_shared, все так и пишут.

со сборщиком мусора ты вообще не должен ничего доказывать.

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

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

На деле нет. С растом о деталях реализации приходится думать меньше, чем с плюсами. Но это если ты понимаешь, что происходит.

и кто победит?

Смотря в чём. Отлаживать и сопровождать проект на расте, скорее всего, будет проще. Хотя, конечно, зависит от проекта и альтернативного языка.

мощной системы типов

это у раста мощная система типов? как-то по диагонали глядел… да нет там никакой потужности!

да нет там никакой потужности!

Всё так. Потужности нет. А мощная система типов есть.

Всё так. Потужности нет. А мощная система типов есть.

«потужность» это мощь по-украински.

посмотрел типы еще раз. никакой потужности. ну почти чисто паскаль.

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

Ну как скажешь.

В расте трейты (характеристики) сделаны по подобию хаскелевских классов типов. Довольно классная штука, если распробуешь. И генерики в расте удобные - полностью проверяются во время компиляции в отличие от твоего сабжа. Классы типов и генерики работают в связке, как и в хаскеле, впрочем. Оттуда это все, из ФП. Попробовав такое раз, хочется уже везде иметь такое.

А вот для шаблонов С++ я приспособился просто писать тесты тупо на прохождение компиляции для инстанцирования шаблонов. Как-то неправильно это.

Инстанцируются генерики раста и шаблоны С++ примерно одинаково в итоге, уже на уровне нативного кода.

В расте трейты (характеристики) сделаны по подобию хаскелевских классов типов. Довольно классная штука, если распробуешь

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

ссылку прилагаю.

https://ru.wikipedia.org/wiki/%D0%90%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BB%D0%B0%D1%81%D1%81

известен еще со времен первых ооп парадигм.

И генерики в расте удобные - полностью проверяются во время компиляции в отличие от твоего сабжа.

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

не void*, а std::unique_ptr

Сожгите еретика

Ты меня смешишь так порою. Нет, это не абстрактный класс, не интерфейс. Трейты в rust - это подобие классов типов из хаскеля. Ни больше, ни меньше. Может быть, еще где-то есть.

Там фишка в том, что через трейт можно задать ограничение на то, какой обобщенный код применять можно, а какой - нельзя. Это во-первых. А во-вторых, там, как это называется, возможна динамическая диспетчеризация. Отдаленно напоминает виртуальные методы - да в программировании все что-то друг друга напоминает.

Что касается шаблонов. Они проверяется при инстанцирования, как ты написал. Но они почти не проверяются без инстанцирования. Я об этом.

Растовский обобщенный код (генерики, в хаскеле это называется полиморфизмом) проверяется на этапе написания до инстанцирования, даже если не было никакого инстанцирования!

Понимаешь, ограничение обобщенного кода по заданному трейту дают контракт, где такой обобщенный код может быть применен, а где - нет.

Подозреваю, что это одна из причин, почему хаскелисты, включая меня, просто тащатся от раста. Именно такой механизм был придуман для хаскеля лет 30-35 назад, может быть, даже раньше. Это все оттуда и с тех времен.

И да, многие цепляются за слова «класс» и «трейт». Похожие слова еще ничего не значат. Предупреждаю

И да, концепты C++ где-то «концептуально» напоминают, но это же страх божий. Классы типов в миллион раз проще и в хаскеле, и в rust

Еще просто, чтобы немного поднять настроение. Вот, в rust есть такая штука как «trait object». Название простое. Если очень грубо, то это что-то типа std::shared_ptr - указатель на базовый класс, а сидеть там может что угодно. Так вот, в хаскеле похожая штука является частью механизма под мудреным названием «existential quantification».

И тут можно сделать перефраз для высказывания из одного популярного фильма - «все уже было придумано до нас»

Если очень грубо, то это что-то типа std::shared_ptr - указатель на базовый класс, а сидеть там может что угодно

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

всего три понятия - класс, наследование, виртуализация метода. и все!!!

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

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

Это как у человеческого языка. На одном можно только тявкать, а на другом - предаваться высокой поэзии.

Вот ты понимаешь, что такое понятие как «trait object» вообще никоим образом не относится к набору абстракций и связей предметной области, а просто какой-то буззворд, который надо куда-то прикрутить, чтобы что-то получить.

какую семантику несет понятие trait object, а какова наиболее наглядная аналогия сему инфошуму в системе абстракций для анализа предметных областей?

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

Если хочешь примера, то растовские трейты хорошо работают для абстрагирования такого понятия как «асинхронное вычисление» (писк моды последние годы). Внезапно, такие вычисления хорошо описываются монадой, а частные случаи последних достаточно легко реализуются на rust через трейты (на С++ тоже можно сделать эффективно, но там нужны приседания с шаблонами). Именно так в начале и появились асинхронные вычисления в rust еще до введения синтаксиса async/await.

Trait object просто стирает тип, обобщает, как std::function в С++ стирает реальный тип замыкания, но позволяет не городить шаблоны.

Понимаешь, какая штука. Ты вот, чую, думаешь, что С++ - прямо пуп Земли, что эталон ООП. А ты вот в курсе, что С++ пошел не совсем по пути ООП, что Страуструп там сильно поотрубал концы. Еще до С++ в языке программирования смолток были блоки. Блок - это та же лямбда-функция с возможностью выхода из контекста (похожее прикрутили в kotlin лет через 40-50) и еще чего-там типа рестартов (по типу common lisp).

То есть, в смолтоке, одном из первых языков ООП, уже в начале на рубеже 70-80 годов было то, что не попало в генеральную линию, намеченную Страуструпом. Он просто не стал брать из ООП то, что не смог реализовать или не посчитал важным. Потом это подхватил Гослинг в той же манере. Это не значит, что ООП - это то, что С++ или Java тебе дают. Так то, границы между парадигмами часто размыты, нет четкой линии, вот тут, понимаешь ООП, а тут не ООП.

У тебя же такие представления, что вот ты знаешь, как сделано в С++, так и пытаешься все подвести под эту картину мира, но мир гораздо шире и богаче. Доношу свою мысль?

И ты, это, завязывай с «пансиплюсизмом»! Книгу от O’Reilly я тебе уже посоветовал выше

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

чтобы понять абстракции си++, надо просто посмотреть хотя бы на UML. вот и посмотри туда.

вот с++ абстракции ложатся на диаграмму классов UML один в один. Как диаграмму классов UML обратить в рустовые абстракции - вообще непонятно.

Ты можешь сказать - мне uml не указ. Хорошо. Предложи другой формализм для системного и структурного анализа, чтобы он красиво отображался в руст. Где есть такая нотация, что позволяет расписывать предметную область, и чтобы она один в один отображалась в руст.

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

Никто не будет изучать рустовые листинги для понимания верхнего уровня абстракций твоей системы. им нужные диаграммы уровня UML. А у тебя в русте просто какие-то костыли, для симуляции классов, наследования и боже мой - «наборов фич» под названием «трейт».

как из всех этих погремушек сформировать нормальные диаграммы? да никак.

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

Какой еще UML в 2025 году? Ты отстал от жизни лет на 25! Это на рубеже девяностых-нулевых годов все тащились от UML (и от COM+ - где вот этот COM+ MTS?). Хотя местами что-то еще используется, но совсем не так, как задумывалось, не с тем масштабом.

Да и посмотри, во что превратили книгу Гради Буча! Когда-то издание где-то второе было просто офигительной замечательной книгой, которая еще до UML. Зачитывался в захлеб. А что потом стало? Книгу Гради Буча в поздних изданиях из интересного материала превратили в какой-то занудный скучный справочник по UML - читать же невозможно стало.

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

Ладно. Закругляюсь. Есть дела, извини! Нет обратной связи - так мне не интересно.

Обращаюсь к другим читателям топика. Посмотрите книгу O’Reilly про Rust! Она стоит того, как стоит того и сам язык Rust. Есть перевод на русском.

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

Мир программирования не огранивается «миром компиляторов». Весь тред пронизан «миром компиляторов». Доминируют в мире программирования не компиляторы. Компиляторы лишь привносят «программирование по понятиям».

Какой еще UML в 2025 году?

uml это просто нотация, отражающая понятийный аппарат системного и структурного анализа.

Этот понятийный аппарат и сам метод анализа существует сам по себе, вне uml(или подобных нотаций) и вне с++/java/sharp/..

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

В русте только одна абстракция хоть как-то адекватная обсуждаемому подходу - трейт. но трейт это «набор фич».

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

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

Уткой является только то, что есть представитель класса утка.

а не «похоже на утку», на утку может быть похоже и изображение в мониторе, и квадробер, утка-робот, и резиновая подсадная утка на веревочке.

а главным обобщающим принципом является высказывание

класс А обобщает класс Б, только если Б наследует от A.

в ООП есть и «наборы фич» , но это просто классы, декларирующие списки методов. Это частный случай классов, и они не заменяют классы.

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

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

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

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

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

но я лично предпочитаю жить в доме, построенному по первому способу.

Для дома по генеральному плану надо иметь готовый точный генеральный план.

В программировании это работает только когда делаешь 100500-й сайт или компьютерную игру.

А когда делаешь, например, учётную систему, то если в генеральном плане указал, что из БД в интерфейс необходимо передать количество элементов (для позиционирования ползунков на списке), то автоматически обвалил производительность системы, так как теперь нельзя просто прочитать первую сотню записей. Или при проектировании не указал ограничение на сортировку по колонкам и при реализации опять выбираешь между тормозами или индексами на все колонки, доступные пользователю (то есть, опять тормозами, но при записи).

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

в ООП есть и «наборы фич» , …

Не хотел публиковать, но всё же часть суждений по ООП опубликую.

ИМХО class C++ лучше использовать как возможность записи более лаконично код и не более того. Но в таком случае можно вполне ограниться использование в коде лишь struct.

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

Что касаемо Rust, то те задачи, которые он приоритетно решает вполне решаемы в C++ путём разработки хорошей подсистемы упроавления памяти. Разработываемое API конечно должно использовать эту подсистему.

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

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

вот пример иерархии, достаточно типичный в задача этого рода. https://hokein.github.io/wxWidgets/classwx_font_dialog.html

просто ткнул в первый попавшийся диалог wxWidgets. тут глубина - 6. и никакой глубиной 2-3 ты тут не обойдешься. ты просто не нарисуешь столь сложный класс с глубиной наследования 2.

короче глубокое (конечно не 100) наследование проистекает из самой предметной области. если она сложно устроена - будет глубокое наследование.

Иногда и классы можно использовать. Главное, чтобы всё продумано было хорошо. В C++ можно «и так и эток». Классы использую лишь в ATL для создания COM и ActiveX.

C++ частенько на форуме критикуют. Но если «не умеешь», то и Rust не поможет, а если «умеешь», то проект на C++ будет добротно работать. От ДУРАКА никакой ЯП не спасёт. Это и есть основная проблема C++.

и никакой глубиной 2-3 ты тут не обойдешься. ты просто не нарисуешь столь сложный класс с глубиной наследования 2.

Любой, сколь угодно сложный, класс можно написать без наследования вообще. Ступени наследования нужны исключительно для типизации. Если где-то есть функции, которым надо именно wxNonOwnedWindow и ничего больше, тогда приходится делать такую глубину. Если таких нет, то спокойно можно оставить EvtHandler / Window / FontDialog с теми же методами и поведением.

Любой, сколь угодно сложный, класс можно написать без наследования вообще.

утверждение равносильно следующему -

Любую сколь угодно сложную функцию можно написать без вызова других функций.

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

зато будет одна. и что мы этим доказали? а доказали мы этим, что функции как раз нужны.

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

Если private не используется, то можно просто struct использовать. Класс и struct ведь родня.

Не равносильно. Функции убирают повторение кода.

Уровень класса эквивалентен флагу в функции. Вот есть wxNonOwnedWindow. Отличается от родителя функцией SetShape (которая работает не везде). С таким же успехом можно было добавить SetShape в wxWindow.

Разделение на wxFrame и wxDialog заставляет копипастить метод Centre и запрещает диалоговые окна с меню и/или статусом.

Если речь про Си++, struct и class почти синонимы. Можно и в struct пихать private.

А заодно в гетах и сетах надобности не будет. Не знаю примеры, когда без гетов и сетов код становился бы хуже. А вот когда плодишь их много, то код становится менее читабельным. Не зря в Microsoft обычно поля структур имеют префикс «m_».

Не знаю примеры, когда без гетов и сетов код становился бы хуже.

Без сетов плохо, когда внезапно добавляется условие, что при записи в поле надо проверять или изменять другое поле. Через operator=() реализуемо, но с сетом проще.

А вот в чём сакральный смысл гетов я не знаю.

Не равносильно. Функции убирают повторение кода.

О чем спор. Вы предлагаете глупость навроде, а давайте все напишем в виде одного класса. Большого такого класса, где все в одной куче.

Я в ответ предлагаю равносильную глупость - а давайте просто напишем код без функций, где все в одной куче.

Вы восклицаете - нет, это неправильная глупость! у меня глупость совсем другая.

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

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

И именно потому и возникнет диаграмма классов, а не по чьей-то воле или частному хотению. то есть диаграмма классов ОБЪЕКТИВНА, и существует как чисто онтологическая конструкция.

а предложение - похерить диаграмму, и все нарисовать одним классом - есть предложение - похоронить вообще знание и представление о предметной области и все нарисовать как единую и неделимую сущность.

И очевидно - это не наш путь.

Так можно просто добавить необходимую функцию.

Несовсем понял что monk хотел сказать. Может быть речь о том, что поля классов могут ссылаться на элементы других классов без всякой иерархии самих классов?

а предложение - похерить диаграмму, и все нарисовать одним классом - есть предложение - похоронить вообще знание и представление о предметной области и все нарисовать как единую и неделимую сущность.

Предложение было уменьшать количество уровней иерархии классов по возможности.

Также, как есть стремление делать функции не больше сотни строки.

А проблема большого уровня иерархии в том, что каждый уровень запрещает какую-либо функциональность во всех ветках кроме одной. Вот понадобится визард с меню и придётся или наследоваться от wxWizard и вручную рисовать меню или наследоваться от wxFrame и дописывать вручную страницы. Те самые «заборы», о которых писал анонимус.

Не знаю примеры, когда без гетов и сетов код становился бы хуже.

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

итак формальный сеттер позволяет

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

• позволяет вообще не иметь такой переменной, а виртуализировать ее наличие.

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

• менять код сеттера в случае отладки или при версионировании, ставить туда точку останова.

формальный геттер позволяет

• делать произвольные действия, а не просто давать результат переменной.

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

• делать кеширование

• менять код геттера в случае отладки или при версионировании, ставить туда точку останова.

это навскидку.

Вообще, если геттер изменяет состояние объекта, это очень неожиданно. Почти как #define true 0.

Так ведь можно для любого из этих случаев просто использовать функции. ИМХО это улучшает читабельность логики кода.