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

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

поясни, что ты хотел услышать?

Ну не иницализация, просто присвоение значений. Почему лучше делать через геттер сеттер?

я хотел услышать как лучше присваивать значение
foo.bar = 42;
или
foo.setBar(42);

Привет. Есть одна^Wодин класс, а в классе поле. Это поле 100% будет будет инициальзироваться в одно действие, и наккой логики при его инициализации / удалении нет

сделай приватный enum. Или приватный static const(хуже). Или просто приватный const(ещё хуже). Как получится.

я хотел услышать как лучше присваивать значение

class foo{
foo() : bar(42) {}
};

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

Ну не иницализация, просто присвоение значений. Почему лучше делать через геттер сеттер?

вообще-то в C++ имеется встроенный сеттер, даже два. Конструктор копирования и оператор=. По дефолту они побайтно копируют все поля. Но можешь перезагрузить. ИМХО если не знаешь, лучше перезагрузи и сделай приватными. Что-бы кто-то случайно не написал bar=42, что вообще может привести к фейлу, ежели 42 преобразуется в bar, а потом туда побитно запишется.

Функции типа set/get удобны тем, что туда ты можешь засунуть какую-то дополнительную логику, не переписывая тонны кода. Если ты абсолютно уверен, что оно тебе не понадобится, то без разницы

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

И заодно ещё спрошу: как православней инициализировать поля в конструкторе?

class foo() {
    foo() : bar(42) {}
}

class foo() {
    foo() {bar = 42;}
}

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

Если поле имеет встроенный или POD-тип, и при присвоении-чтении никаких дополнительных действий (типа флажков, логирования) не производится, геттеры-сеттеры не нужны. Серьёзно. Keep it simple.

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

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

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

Забыл отразить это в примере, но в случае с C(a) для поля a сначала будет вызван конструктор без аргументов, а потом уже будет произведено присваивание. В простых случаях ничего страшного, но вообще такие вещи надо иметь в виду.

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

используй operator=() для копирования. Это такой сеттер. И/или конструктор копирования(для инициализации). Если это не нужно, просто сделай их пустыми и приватными.

И заодно ещё спрошу: как православней инициализировать поля в конструкторе?

конечно foo() : bar(42)

Это специальная форма, и иногда правильно работает только она. Другой способ не правильный. К тому-же, первый вариант НЕ нуждается в коде, т.е. может быть намного быстрее. (хотя умный компилятор может догадаться, что второй вариант тоже не требует кода. У тебя умный компилятор и ты тоже умный? Тогда пиши как хочешь).

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

это C++. Тут _только_ через сеттер. Напрямую не получится(т.е. можно foo.bar =42, но это быдлокод, если конечно foo не POD.

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

+1, однако class в struct можно и не переименовывать. (хотя стилистически лучше переименовать)

есть книжка хорошая, scott meyers effective c++. Там написано про все что ты спрашиваешь и даже больше!

Другой способ не правильный.

другой тоже правильный, только вызовет сначала дефолт констрактор а потом копи констрактор

другой тоже правильный, только вызовет сначала дефолт констрактор а потом копи констрактор

думаешь, ТС этого ждал?

а потом копи констрактор

Оператор присваивания

Срочно прочти Майерса. У него как раз про то что ты спрашиваешь.

Почему лучше делать через геттер сеттер?

Это такая религия.

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

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

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

при «ЖЕЛАНИИ» функция злоумышленик сможет писать твоё приват поле через приведение к структуре и записи по нужному смещению.

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

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

не делай досрочной сверхобобщённости . пусть публичное поле.

ну и вообще может тебе структуры достаточно?

покури Страустропа(ага это тот кто С++ )

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

посмотри на абстракции как на общие протоколы/интерфейсы.

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

О, спец в треде.

Структуры недостаточно, мне там нужен интерфейс.
Вот сверху ещё посоветовали писать getter / setter в хедере. Можно же явно сказать inline и тогда будут счастливы все - и фанаты java и те кто за скорость. Это хорошая идея?
И да, сработает ли инлайн при присвоении к приватному полю?

Инлайны!) спасибо, надо обдумать

use c++11

class X {
   X()
...
   int n=5;
   Foo bar(1,"foofoofoo");
...
}

X(){
  //n, bar инициализованы
}

да у меня вообще pod поля) Но это интересные штуки, конечно.

!! Спасибо, это действительно хорошая идея) Как я понимаю, это будет аналогично X() : n(5), bar(1,«foofoofoo») {} ?

Спасибо!

а с pod полями разницы нет, так?

Да

полу грамотность сочетает в себе худшие черты не грамотности и грамотности

тебе вообще зачем обьект в сравнение с pod?

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

да. но! гцц4.6 не умеет этого. 4.7 и llvm3.1 умеют

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

в C++ имеется встроенный сеттер, даже два

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

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

Мне нужно полиморфное поведение кода.

у меня арч

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

Вот сверху ещё посоветовали писать getter / setter в хедере. Можно же явно сказать inline и тогда будут счастливы все - и фанаты java и те кто за скорость. Это хорошая идея?

плохая. Потому-что это НЕ Java. Будет ява - спроси у кого-нить ещё.

И да, сработает ли инлайн при присвоении к приватному полю?

конечно да. Он может НЕ сработать с пабликом, если этот паблик где-то далеко (в хидере например). А с приватным полем ты его от кода не оторвёшь.

да у меня вообще pod поля

тогда совет выше - будь проще, не заморачивайся. Делать тут конструкторы/сеттеры == получить по роже. Ибо от тебя твои товарищи такого не ждут. Кому-то придётся ночку в дебагере посидеть. из-за тебя.

Хотя синтаксис и позволяет конечно…

твой ответ саморекомендация себе курнуть lang def C++

Спасибо, это действительно хорошая идея) Как я понимаю, это будет аналогично X() : n(5), bar(1,«foofoofoo») {} ?

типа того. Напоминает

if (cmd[1] == RESET)    // если принятая команда RESET
{((void(*)(void))0)();} // что-то из черной магии

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