Правильная инициализация поля в C++

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

дык вот про C++

Вытаскивая переменную-член в паблик ты нарушаешь инкапсуляцию, перестаешь контролировать инвариант и убиваешь котенка.

©Правильная инициализация поля в C++ (комментарий)

Хорошо, что хоть это меня не пугает)

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

возможно в кавычки. Хотя ИМХО x=y; это ЯВНЫЙ вызов конструктора/оператора=. Даже если его компилятор неявно поставил. Просто так писать короче/проще.

ну а если не pod, но с таким же повидением. Какой смысл?

имеется ввиду инлайновая публичная функция, в которой происходит присвоение п приватному полю. Компилятор заинлайнит?

не знаю. ЕМНИП по стандарту может, но не обязан. А присвоение ИМХО тут не при чём. На уровне машинного кода всё - public. Т.е. если взять указатель на приватное поле, отдать его как void*, а потом преобразовать в int*, то можно такое поле смело менять, будь оно трижды приватное и константное. Добро пожаловать в C++ ☺

ну а если не pod, но с таким же повидением.

ИМХО pod это и есть - поведение. А называться оно по разному может. В C++11 pod теперь помягче стал.

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

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

В C++11 pod теперь помягче стал

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

Судя по стандарту, pod теперь не обычный встроенный тип, он может быть классом

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

Б-г мой...

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

Иначе это клинический случай ООП головного мосга.

ok

Так и я о том же. Для POD - присваивание, для остального - сеттеры, взболтать, но не смешивать.

это вера - о будущем в котором понадобится.

может вообще обьект на другую машину/или как минимум другой процесс вынесите для «ещё более лучшей» инкапсуляции? а почему не?

Вытаскивая переменную-член в паблик ты нарушаешь инкапсуляцию, перестаешь контролировать инвариант и убиваешь котенка.

Да, не надо вытаскивать член в паблик! Не поймут...

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

Если по сути изменение поля снаружи не несет никакой угрозы (не требует согласованных изменений других полей)

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

Си++: как нафлудить 2 страницы на Лоре, обсуждая инициализацию int поля.

А потом раз - у королевы вырастут тестикулы и она станет королем.

Если на этапе проектирования не была замечена такая необходимость - ССЗБ. А потом, с таким подходом, получаются космические корабли которые используют для копания картошки. «Наша библиотека охренительно гибкая и дуракоустойчивая, но что бы начать с ней работу вам придется изучить 100500 страниц дрокументации, и вы все равно не сможете с ней работать потому что каждый пук там делается через свой геттер-сеттер-аллокатор-транзакатор.»

Люди, пишущие проекты где это по делу востребовано, таких вопросов на ЛОРе не задают.

Это проблемы не языка а некоторых особо одаренных товарищей на этом языке пишущих;-)

Если на этапе проектирования не была замечена такая необходимость - ССЗБ

за пределами страны эльфов ССЗБ на этапе проектирования встречается не так уж редко.

каждый пук там делается через свой геттер-сеттер-аллокатор-транзакатор

get/setFooBar - чуть не стандарт из стандартов, и в плане документации ничем не отличаются от паблик свойств.

тут такое дело.

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

ООП предшествовали всякие Симулы и теория агентов(акторов http://ru.wikipedia.org/wiki/Модель_акторов

http://en.wikipedia.org/wiki/Actor_model_theory

которую успешно и сейчас развивают) -а ООП как раз и оказалась тем эффектом падения «скорости»-качества концептуально .

у тех же лямбд /замыканий/ goto/ акторов - реально матан

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

ща вот objC постеменно замещает С++ ибо чистая производительность перестала быть узким местом на клиентах . а на серверах можно и на маш коде если приспичит проценты выжимать.

в ООП навалено в кучу модульность/абстрактные_типы_данных и т.п.

короче ООП это не наука ибо куча слов с большой буквы (Поли,Инка,Насле) и меньше 10% матана - очень маркетинго насыщенная весч.

с мириадами шаблонов проектирования - ПТУ на марше.

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

И кто мешает добавить сеттер?

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

если так упирать на хрупкость библиотеки то с чего С++ то юзать ?

если пишиш прототип то нафига на С++?

а уж если на С++ то почему обязательно через ООП а не родовое?

И кто мешает добавить сеттер?

Добавить - ничего. Но если раньше наружу торчало поле и везде использовалось, то придется искать и переписывать bar.foo=z на bar.setFoo(z). Сие занятие достаточно веселое даже в собственном проекте, а если это дело еще использовалось другими людьми в составе библиотеки - то ой.

самым частым ответом на вопрос «нафига на C++» пока что является «этот мир придуман не нами».

И да, я на плюсах не пишу практически.

Вот только зачем статик конст высовывать наружу, если его не юзают?

например нужно тебе сделать константу - не скаляр.

придется искать и переписывать bar.foo=z на bar.setFoo(z). Сие занятие достаточно веселое даже в собственном проекте

Сие банальщина.

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

короче ООП это не наука ибо куча слов с большой буквы (Поли,Инка,Насле) и меньше 10% матана - очень маркетинго насыщенная весч.

с мириадами шаблонов проектирования - ПТУ на марше.

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

Чтож никто не пишет на Хаскеле?)

вот и мне интересны причины(генетические) от чего при обучении

троица Инкапсуляции, Наследования и Полиморфизма автоматически

приобрела святость «ибо так и ни как иначе» о организации(устройстве их и отношениях между их [чертежами]«синками»(классами)) обьектов.

Вытаскивая переменную-член в паблик ты нарушаешь инкапсуляцию, перестаешь контролировать инвариант и убиваешь котенка

здесь ещё видна (само)ирония.

Есть вероятность, что в будущем потребуется добавить эту самую дополнительную логику

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

в результате «астронавты космической абстракции» на марше.

А можно вообще не думать о будущем и переписывать код каждый раз, как изменяются требования

Обоснование будущем вообще замечательное «Причина для всего»

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

почему ваша программа резервирует гиг памяти при пуске «в будущем пригодится»

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

зачем ваша програма ... «в будущем пригодится»

*если бюджет позволяет - ок.

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

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

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

Так и я о том же. Для POD - присваивание, для остального - сеттеры, взболтать, но не смешивать.

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

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

никуда мы не приплыли, если это внутренний POD. А если он наружу торчит - ССЗБ. Приплыли уже давно.

некоторые пишут[на хаскеле].

я не пишу[на хаскеле] ибо «не вижу» на каких задачах его использовать.

категории (th) пока не понимаю.

при чём тут вообще хаскел? зачем противопоставлять языки?

есть задача - делаеш как умееш .

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

клиенты должны через методы общаться, а не через данные-члены. Тогда ничего переписывать не придётся. Для этого можно и ИМХО нужно закрыть данные в сервере, и открыть и написать геттеры/сеттеры. А вот сам сервер может и напрямую, если он простой(из одного модуля). Если это какой-то суперсервер, который пишут Over9000 кодеров - то вопрос неоднозначный. Возможно самое ядро(ядра) этого сервера могут и забить на инкапсуляцию, и работать напрямую. Не знаю, от гайдлайнов зависит, т.е. как эти кодеры договорятся.

Однако с клиентами вопрос однозначный - пулемёта^Wpod им давать НЕ нужно.

http://ru.wikipedia.org/wiki/Haskell#.D0.A7.D0.B8.D1.81.D0.BB.D0.B0_.D0.A4.D0...

вот по этому.

Seasoned professional in http://www.gnu.org/fun/jokes/helloworld.html

троица Инкапсуляции, Наследования и Полиморфизма автоматически приобрела святость «ибо так и ни как иначе»

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

Пойми - исключения возможны, но приводят к проблемам, о которых должны ВСЕ помнить, кто к этим исключениям имеет доступ. Если класс сложный, то даже единственный разработчик всё в голове удержать не сможет. Потому и применяют Инкапсуляцию. А наследование и полиморфизм - что-бы хоть как-то можно было эту инкапсуляцию применять. Без них не взлетит.

Это не костыли, это оградки, которые сделаны для того, что-бы кто-то случайно не навернулся.

вместо этого :

fib n = head (apply (Matrix [[0,1], [1,1]] ^ n) [0,1])

from 3.1 Using 2x2 matrices http://www.haskell.org/haskellwiki/The_Fibonacci_sequence

пойми ООП - это исключительная ситуации требующая соблюдения приреквеста.

нет приреквеста - лесом ООП.

ты посмотри , что он НаследованияТМ бегут

ибо ИнтерфейсыТМ

хаскел привел как язык,полный «матаном» чуть менее, чем полностью

Seasoned professional in http://www.gnu.org/fun/jokes/helloworld.html

не очень Seasoned, диструктор должен быть виртуальным, ибо при наследовании от этого string возможны проблемы с освобождением памяти. А в остальном - вроде годно. Хотя читал код по диагонали.

И ты зря смеёшься - данный код глуп потому только, что для вывода helloworld УЖЕ есть код в iostream. Да и вообще в STL есть свой string, какой смысл писать свой? Но если-бы в STL этого не было-бы, то именно так я и написал-бы.

пойми ООП - это исключительная ситуации требующая соблюдения приреквеста.

не понял. объясни подробнее.

а зачем 100% матана в практике

понимание какова доля матана потребна в решаемой проблеме и есть матан

использование игнорирование контекста постояной доли матана ( и не важно ООП(10%), Наскел(100%) , что-либо-ещё(сonst%)) - и есть признак специфической специализации см Аристотель Политика

ибо ИнтерфейсыТМ

дык это не C++. Не знаю, может и годно, но при чём тут C++?

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

тебе тогда Правильная инициализация поля в C++ (комментарий)

см. Страустроп Дизайн и эволюция С++

С++ не ограничивается ООП.

абстрактный класс как отказ от наследования реализации с сохранением полиморфизма.