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

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

любой НЕ хэлловорд к этой фазе приходит ещё до первого релиза. Исключение - коротенькие скрипты, которые удобно писать на bash'е или там php каком-нить.

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

мне матан не нужен, я и по опыту знаю, что что-то сложнее хелловорлда написать без ООП невозможно.

любой НЕ хэлловорд

вольному воля.

ок

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

только не для меня :)

публичный поле-член.

факт связности клиентов к классу(«as») обьекта владельца-поля вне зависимости скрыто ли поле и «доступно» через гетер или присутствует в открытом доступе.

Ядро!
Не знаю как там с ооп, но С точно его не умеют. Ну на уровне языка.

Я запустался.

class A {
private:
bool debug_printing = false;
public:
void setDebugPrinting();
};

class A {
public:
bool debug_printing = false;
};

И таки ещё вопрос: void set() или void set(void). Разницы же нет?

Ядро! Не знаю как там с ооп, но С точно его не умеют. Ну на уровне языка.

у меня для тебя плохие новости - C Тьюринг Полный ЯП, и на нём можно писать что угодно. В частности можно скрывать переменные, хоть и на уровне файлов, а не классов (ptivate). Виртуальные функции тоже сделать несложно, в т.ч. и чистые. Выглядит это всё жутко и убого, но таки работает. И в ядре тоже.

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

Господа аналитики, вот эта ситуация. Флаг отвечает за то, что в процессе работы будут принтоваться штуки.

ключевой вопрос: КОМУ можно ставить этот флаг? Если это какой-то внутренний флаг, то юзай присваивание. Если класс торчит наружу, сделай член приватным, а если класс не торчит, то можно и так (вопрос скорее стиля и аккуратности).

Но если кто угодно может и должен дёргать этот флаг, то setDebugPrinting(); ОДНОЗНАЧНО.

И таки ещё вопрос: void set() или void set(void). Разницы же нет?

нет вроде. Но второй вариант много лет почти никто не использует. Может он уже depricated, а может даже где-то не работает.

я и по опыту знаю, что что-то сложнее хелловорлда написать без ООП невозможно.

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

тонны геттеров/сеттеров для POD которые ничего не делают, означает только одно: надо убрать их убрать и переименовать class в struct.

люто плюсую

:)

class A {
bool debug_printing = false;
}

если споткнёшся на доступе или вставиш public или добавиш friend :)

void set() или void set(void)

в С точно разница . в С++ - смотри стандарт для полной уверености.

надеюсь класс не состоит из одного тока поля.

Не так и не так. Зачем делать внутри каждого класса поле признака отладки, если отладочные опции у тебя, скорее всего будут задавться не только для для этого класса и не на уровне класса, а на уровне программы и твоя программа будет проверять эти опции на этапе инициализации, ещё до создания твоих классов? Просто сделай общий базовый класс для всех своих классов и задай в нём protected static debug_options, с сеттером (который возможно сам и будет парсить эти опции). Определи enum с возможными опциями отладки. А там, где в своём классе A ты делал бы if(debug_printing)print(something); делай if(debug_options&DEBUG_PRINTING)print(something);

Не знаю по чему ты учишься, но ты точно делаешь это не правильно. Совет, завяжи пока с ООП (пока!) и начни изучать STL,как поймешь всю структуру ООП, переходи к самому ООП.
Превью: STL дает понять что кол-во публичных полей не должно быть вообще должно сводиться к минимуму, все операции с объектом должны быть предусмотрены разработчиком, и проводиться через паблик методы.

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

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

stl хороша «слабостью»

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

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

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

вообще-то STL это принципиально другое. С ООП просто ортогонально. Есть в C++ ООП без всякого STL, да и шаблоны вообще говоря к ООП прямо не относятся. Просто в C++ шаблоны приколочены к классам, как и ООП. Потому STL косвенно прибито гвоздями к ООП.

А какая разница то?

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

эт дебаг флаг вдля включения дебага в бизоне. Он тут не случайно.

xmonad же! :D

xmonad

это из серии «калькулятор на sed» и «морской бой на brainfuck». Можно, и уже сделано и работает. Ещё можно бочку сделать.

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

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

Определись ;-)

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

В этом топике речь про практику применения инкапсуляции для отдельной переменной-члена в C++.

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

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

если растягивать ООП на всё то да.

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

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

нО считать ,что ООП это единственный способ борьбы со сложностью это переопределять что есть ООП.

и в этом смысле(борьбы со сложностью) представление об независимо процесерующих акторах более адекватно картине мира

чем называние вызова сообщением модное в ООП

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

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

(void) - это гарантия , что функция не использует совсем аргументы

как в С++? - смотри стандарт.

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

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

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

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

тред не читал. поясни, как без троицы использовать ООП?

что ты , что ты вероучение ООП без святой троицы (Инка,Насле,Поли) есть ересь на ООП.

Инка есть модульность и атд.

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

Насле(реализации) есть жадность менеджеров и этого достаточно.

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

ксати

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

берёш и вместо n-арных методов - все аргументы загоняеш в поля обьекта , затем вызываеш метод.

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

По дефолту они побайтно копируют все поля.

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

Это си-то функциональный? Завязывай с наркотиками.

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

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

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

Если ты не определил конструктор копирования, то его определит за тебя компилятор. И это будет не побайтовое копирование, а вызов конструктора копирования для каждого твоего поля.

Если ты не определил конструктор копирования, то его определит за тебя компилятор. И это будет не побайтовое копирование, а вызов конструктора копирования для каждого твоего поля.

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

Хм, разе это не делается через синглентон логгер? Который уже сам берёт на себя решение, выводить сообщение или нет.
Не помню, как Александреску-правословно выглядит вызов.

Nope. Вполне готовый прдукт, много расширений. Просто никто не волнуется по поводу популяризации, те. конфиг на haskell вполне всех устрает.
Ну и http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html

Nope. Вполне готовый прдукт, много расширений. Просто никто не волнуется по поводу популяризации, те. конфиг на haskell вполне всех устрает. Ну и http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html

ну кто ж спорит? Там же ясно написано: «Haskell for all», что тут непонятного? Занимайтесь. Это стильно, модно, молодёжно.

Однако твое утверждение о том, что если ты не определил конструктор копирования для своего типа, то по умолчанию будет побайтовое копирование, остается НЕВЕРНЫМ. Иначе нельзя было бы создать тип с полем, например, std::string, не определив своего конструктора копирования. По умолчанию будет вызов конструктора копирования для каждого поля. И это принципиально отличается от побайтового копирования.

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

Однако твое утверждение о том, что если ты не определил конструктор копирования для своего типа, то по умолчанию будет побайтовое копирование, остается НЕВЕРНЫМ.

да, буквоед, ты победил.

Важнее другое - если забыть сделать конструктор копирования, его сделает компилятор. И не очень важно, будет или нет там побайтное, или побитное копирование. Важно то, что этот дефолтный конструктор будет работать и инициализировать НЕ ТАК, как надо.

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

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

Важно то, что этот дефолтный конструктор будет работать и инициализировать НЕ ТАК, как надо.

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

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

о том и речь. А во многих x=y будет работать не так, как хочется.