Правила создания конструктора, подскажжжите

[pproger]

Сообщение от Vladiger

Разумеется, а разве я где то претендовал на Авторство?
Я даже более скажу, скажу откуда скопипастил:
DirectX Software Development Kit в состав SDK входит графический интерфейс DXUT, открытость кода и никаких запретов на макросы я не нашел.

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

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

[Igor95]

Сообщение от _Bers

Vladiger,

1. Без видимой причины не нужно делать данные приватными.

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

3. Методы, определенные в декларации класса по стандарту уже являются inline. Не нужно дополнительно указывать это компилятору.
К тому же, современные компиляторы стали достаточно умны. Умеют инлайнтить даже те методы, которые разбросаны по разным единицам трансляции.

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

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

Актуальность сохраняют ключевые слова, например: __forceinline
Это расширение от компилятора майкрософт.
Приказ компилятору инлайнтить функцию "крутись как хочешь, но сделай".
Неаккуратное использование может просадить производительность.

Насчет первого пункта:
Если поведение объекта - реакция на изменение состояния его свойства...то, если мы не скроем свойства, то будет нарушена инкапсуляция и это будет уже не объект, а обыкновенный экземпляр фактически структуры (если уж область видимости - весь остальной код).
Таким образом, нарушив инкапсуляцию:
- клиент может рассматривать абстракцию не так, как того ожидает разработчик. Т.е клиент использует абстракцию не по назначению.
- не локализируются данные, тем самым труднее найти ошибку и легче ее допустить
- стирается грань между реализацией поведения объекта и его контрактными обязательствами. Зачем клиенту контракт, если данные итак на виду... их можно взять, изменить и без контракта. Инкапсуляция это пресекает.
При инкапсуляции мы бы изолировали данные и контрактные обязательства объекта, а в случае адаптации программы под новые требования просто изменили бы способ реализации поведения (т.е данные), не затрагивая интерфейса. Оставляем контракт тем же, а способ реализации меняем.

[_Bers]

Сообщение от Igor95

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

Не обязательно. Вот например:

Calculator calculator;

calculator.mSafety = Calculator::eMAXIMUM;

...

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

//инкапсуляция не нарушена

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

Set(Param param){ mParam = param; }

[Igor95]

Сообщение от _Bers

Не обязательно. Вот например:

Calculator calculator;

calculator.mSafety = Calculator::eMAXIMUM;

...

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

//инкапсуляция не нарушена

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

[Vladiger]

Сообщение от pproger

не понимая, что это костыль. костыль из начала 90-х.

Сообщение от pproger

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

Я действительно так и не понял, почему костыль то? Почему плохо? Точнее кому плохо?
Человек пишет свой класс chelovek, который в дальнейшем будет использовать в своей программе. Так он уже пишет новую конструкцию, а Вы говорите что "это плохо".
А потом читая его код Вы будете говорить что класс chelovek сбивает Вас с толку? Отвратительно?

Сообщение от pproger

да еще и людям советуешь его использовать.

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

Сообщение от Vladiger

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

Ну да ладно, пускай будет по вашему, предположим "советую". Только все это напоминает мне Сталинские репрессии, железный зановес СССР. Обмен информацией расценивается как распространение порнографии (факт которой пока не доказан), а уж если "советую" - ну тут вообще растрел на месте...
Ну так подотрите их на правах модератора, что бы никто не увидел случайно эти макросы, а то не дай Бог к завтрашнему дню тысячи студенотов используют их в своих дипломных работах.

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

Сообщение от _Bers

1. Без видимой причины не нужно делать данные приватными.

Сообщение от Igor95

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

Так нужно их делать приватными или не нужно? Что есть зло? И чем макросы отличаются от этих противоречий?
Для Вас костыли, другие не брезгуют. Вы всех будете призывать к написанию в стиле WinAPI strcpy(), strcat() и.т.д.. и.т.п... что бы с толку не сбивало?
Я уж боюсь предположить что будет если я какую нибудь стороннюю библиотеку подключу, в ней ведь свои конструкции будут и своё API...

[still_alive]

Это не второй конструктор, это перегруженные функции основного конструктора, который может быть только один. Если Вам удобнее для понимания, назовите её "дубликат" конструктора.

А основной конструктор это что такое? Как-то не встречался с этим термином.

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

Не, не вариант, это ж не питон, где можно при вызове функций именовать параметры.

Конструктор - это тоде метод

Режет глаза, в плюсовой терминологии слова "метод" нету)

Более того, в именах переменных, не плохо бы ссылаться и на их тип, по этому поводу тоже есть некие правила. То есть если переменная строка, то в вашем случае гораздо "вежлевее" было именовать переменную imya как strName, а переменные intiger можно было именовать как nAge, а не vozrast.

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

1. Без видимой причины не нужно делать данные приватными.

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

PS макросы эти нафиг, они в иде не всегда удобны и для грепа тоже.

[Vladiger]

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

А эти тоже нафиг?

min(a, b)
max(a, b)
MAKEWORD(a, b)
MAKELONG(a, b)
LOWORD(l)
HIWORD(l)
LOBYTE(w)
HIBYTE(w)
ZeroMemory(pb, cb)
FillMemory(pb, cb, b)
CopyMemory(pbDst, pbSrc, cb)
MoveMemory(pbDst, pbSrc, cb)

[Igor95]

Режет глаза, в плюсовой терминологии слова "метод" нету)

Имеется в виду, что это - специальный метод

Сообщение от Vladiger

А эти тоже нафиг?

min(a, b)
max(a, b)
MAKEWORD(a, b)
MAKELONG(a, b)
LOWORD(l)
HIWORD(l)
LOBYTE(w)
HIBYTE(w)
ZeroMemory(pb, cb)
FillMemory(pb, cb, b)
CopyMemory(pbDst, pbSrc, cb)
MoveMemory(pbDst, pbSrc, cb)

Есть и безмакросовые аналоги.

[_Bers]

Сообщение от still_alive

Режет глаза, в плюсовой терминологии слова "метод" нету)

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

Лаконичный синоним словосочетания member function, использующий
__thiscall calling convention

Сообщение от still_alive

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

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

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

"Сегодня мы напишем сеттер, потому что завтра помимо тупого присвоения, нам возможно понадобится валидация нового значения. МЫ ЭТОГО НЕ ЗНАЕМ. Мы не знаем что будет завтра. Поэтому пишем код, который максимально безболезненно переносит изменения".

Скользкий путь рефакторинга, овер-инжениринга.

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

Это проблема механизма в целом: он отвратительно спроектирован, слишком сложен, им не удобно работать.

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

[still_alive]

Имеется в виду, что это - специальный метод

Это верно, но в общих терминах ООП. А в плюсах конструктор - это и есть конструктор) Наверное, никто не понял, что я хочу этим сказать, но да ладно)

А эти тоже нафиг?

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

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

Не особо верится. Сможешь найти мне в стандарте хоть одно упоминание о member function как о method?

Наоборот - это распространенное заблуждение.

Не понял почему.

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

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