Пишем свой класс, спецификатор доступа protected

Nishen · Регистрация: 26.02.2015

Author24 — интернет-сервис помощи студентам

Всем привет!
Из книги Р. Лафоре относительно спецификатора доступа protected:

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

Далее пишется следующее:

Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private.

Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private?

@Avazart · 10.07.2015, 14:52

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

Либо все время проверять дату на валидность и не допускать левых дат.

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

@ct0r · 10.07.2015, 14:58

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

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

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

PS где-то я уверен, что передаю верные данные. Где-то не уверен. И здесь правильный подход - проверять корректность в использующей класс части только там, где нужно. Этим и будут сохраняться инварианты класса и избегаться UB. А в классе оставить только ассерты и не пытаться сохранить инварианты любой ценой.

@Avazart · 10.07.2015, 15:03

К примеру

C++

Date from,to;
 
from.setDate(" .... ");
to.setDate("10.07.2015");
 
int days=  daysBetween(from,to);
 
std::cout<< days <<std::endl;

Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов:

1. from - задано невалидным
2. to - задано невалидным
3. daysBetween() работает не верно.

Добавлено через 3 минуты

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

Только мне кажется, что ты говоришь о всем приложении в целом, а я о проектировании библиотечного класса

А библиотечные классы не строятся один на другом?

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

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

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

@ct0r · 10.07.2015, 15:12

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

Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов:

Само собой. Но проверки - это не обязательно ответственность именно класса.

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

А библиотечные классы не строятся один на другом?

Какая разница? Всегда есть используемый класс и использующий.

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

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

Да, очевидно, что контракты должны быть прописаны в документации и ассертами.

Добавлено через 3 минуты
Совсем хорошо, если еще негативные тесты есть.

@Avazart · 10.07.2015, 15:20

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

Какая разница? Всегда есть используемый класс и использующий.

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

Добавлено через 2 минуты

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

Само собой. Но проверки - это не обязательно ответственность именно класса.

А кого тогда эта ответственность?
Класс должен отвечать за то что ему поручают, т.е за то с чем его ассоциируют,
Класс "дата" не должен хранить класс "строку" ( как в моем примере: from.setDate(" .... "); ) он должен хранить именно дату, а не что иное.

@hoggy · 10.07.2015, 15:23

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

То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске.

мне не интересны дешовые понты.
не пишите мне больше.

@ct0r · 10.07.2015, 15:33

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

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

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

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

А кого тогда эта ответственность?

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

Добавлено через 3 минуты

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

мне не интересны дешовые понты.
не пишите мне больше.

Хорошо. Не вижу смысла вам писать, раз уж сами не можете потратить минуту на поиск информации. Я в няньки не нанимался.

@Avazart · 10.07.2015, 15:42

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

то либо оберни в свой

Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализацию с проверками зачем мне мараться.

Добавлено через 1 минуту

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

Но изначально предоставлять класс со всеми проверками - не лучшая идея.

Не лучшая идея допускать UB cо старта.

Добавлено через 56 секунд

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

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

Тому кто использует срать, он хочет получить желаемое, а не UB.
UB на то UB а не гарантированое повидение.

Если вы изначально UB приравниваете/(включаете) к гарантированному поведению то грош вам цена как программисту.

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

@ct0r · 10.07.2015, 15:46

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

Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализации зачем мне мараться.

То есть для тебя читать документацию означает мараться? Ну ок

Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?

Добавлено через 1 минуту

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

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

Оу, почитайте про DbC на досуге.

@Avazart · 10.07.2015, 15:49

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

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

Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?

А с чего начинать со специализированных классов?
С таким же успехом можно было уже и назвать std::pair<> в котором члены класса открыты.

Вы ведь сами изначально привели пример с датой изначально так?

@ct0r · 10.07.2015, 16:05

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

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

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

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

А с чего начинать со специализированных классов?
С таким же успехом можно было уже и назвать std:

air<> в котором члены класса открыты.
Вы ведь сами изначально привели пример с датой изначально так?

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

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

@Avazart · 10.07.2015, 16:19

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

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

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

Добавлено через 4 минуты

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

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

Тем не менее не плохо бы что бы микроволновка не допускала включение при открытой дверце.

@Voivoid · 10.07.2015, 16:28

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

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

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

@ct0r · 10.07.2015, 16:34

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

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

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

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

Тем не менее не плохо бы что бы микроволновка не допускала включение при открытой дверце.

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

Добавлено через 2 минуты

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

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

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

@Avazart · 10.07.2015, 17:06

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

Так кто все-таки виноват?

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

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

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

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

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

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

К примеру, а если в моем городе не принято читать документацию?

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

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

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

Я не говорил что нужно доводить все до абсурда и пихать проверки куда не нужно.

@ct0r · 10.07.2015, 17:36

Avazart, вернемся к теме.

Чел написал всем известную книгу:
http://www.amazon.com/Large-Sc... 0201633620
http://stackoverflow.com/quest... are-design

Его слова с аннотации к выступлению на CppCon14 (выделения мои):

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main.

Ты с ним не согласен?

@Avazart · 11.07.2015, 01:59

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

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

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

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

Добавлено через 9 минут

Не по теме:

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

Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?

Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at().

Добавлено через 16 минут

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

Avazart, вернемся к теме.

Что касается изначальной темы и авторов книг:

41. Делайте данные-члены закрытыми (кроме случая агрегатов в стиле структур С)

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

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

Герб Саттер, Андрей Александреску "Стандарты программирования на С++ 101 правило и рекомендация "

http://bookscafe.net/read/satt... idp1948512

@ct0r · 11.07.2015, 02:52

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

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

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

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

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

Ну а если нужна? Да и какие талмуды? Что именно должно документироваться, написано в вики https://en.wikipedia.org/wiki/Design_by_contract

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

Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at().

Это только у вектора.

@Avazart · 11.07.2015, 03:00

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

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

Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри".

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

Да и какие талмуды? Что именно должно документироваться,

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

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

Это только у вектора.

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

@ct0r · 11.07.2015, 03:12

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

Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри".

Двойной интерфейс как вариант. По сути это и есть готовая обертка - вызовы внутри будут делегироваться к коду без проверок.

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

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

В случае без проверок мы документируем, как правильно надо пользоваться, остальное - UB. В случае с проверками нам помимо этого нужно расписать, как либа сообщает об ошибках (исключения, коды ошибок, запись в лог, какие-нибудь Maybe монады) и какие именно ошибки в каком случае возвращаются. Кажется, что во втором варианте писать больше, разве нет?

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

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

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

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 15:12	44
	Сообщение от Avazart Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов: Само собой. Но проверки - это не обязательно ответственность именно класса. Сообщение от Avazart А библиотечные классы не строятся один на другом? Какая разница? Всегда есть используемый класс и использующий. Сообщение от Avazart Должен быть уверен в том что ты проверяешь, как должна быть осуществлена проверка что бы не допустить багов должно быть отображено в документации библиотеки. Да, очевидно, что контракты должны быть прописаны в документации и ассертами. Добавлено через 3 минуты Совсем хорошо, если еще негативные тесты есть. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 15:20	45
	Сообщение от ct0r Какая разница? Всегда есть используемый класс и использующий. Да любой класс используемый, вопрос уровня. Для того и пишут классы- для возможности повторного использования, а не копипаста кода. Вот как раз отсутствие проверок и делает код непригодным к повторному использованию ибо "человек" должен слишком много знать об этом кривом классе и слишком много сделать проверок руками... и возможно окажется что легче будет писать с нуля нежели использовать этот класс. Добавлено через 2 минуты Сообщение от ct0r Само собой. Но проверки - это не обязательно ответственность именно класса. А кого тогда эта ответственность? Класс должен отвечать за то что ему поручают, т.е за то с чем его ассоциируют, Класс "дата" не должен хранить класс "строку" ( как в моем примере: from.setDate(" .... "); ) он должен хранить именно дату, а не что иное. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 15:33	47
	Сообщение от Avazart Да любой класс используемый, вопрос уровня. Для того и пишут классы- для возможности повторного использования, а не копипаста кода. Вот как раз отсутствие проверок и делает код непригодным к повторному использованию ибо "человек" должен слишком много знать об этом кривом классе и слишком много сделать проверок руками... и возможно окажется что легче будет писать с нуля нежели использовать этот класс. Вообще не вижу проблем. Если у тебя такая ситуация, что на каждый чих что-то надо проверять, то либо оберни в свой, в котором будут проверки, либо воспользуйся уже такой готовой оберткой. Но изначально предоставлять класс со всеми проверками - не лучшая идея. Сообщение от Avazart А кого тогда эта ответственность? Тот, кто его использует, обязан проверять, что он следует контракту используемого класса для того, чтобы получить гарантированное поведение. Добавлено через 3 минуты Сообщение от hoggy мне не интересны дешовые понты. не пишите мне больше. Хорошо. Не вижу смысла вам писать, раз уж сами не можете потратить минуту на поиск информации. Я в няньки не нанимался. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 15:49	50
	А при чем тут дока? Если кривая библиотека, то и получишь документацию к кривой библиотеке не более. Сообщение от ct0r Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как? А с чего начинать со специализированных классов? С таким же успехом можно было уже и назвать std::pair<> в котором члены класса открыты. Вы ведь сами изначально привели пример с датой изначально так? 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	10.07.2015, 16:28	53
	Сообщение от ct0r Библиотека не кривая. Если ты ее используешь не так, как задумано авторами (как задумано - написано в документации) - это твои личные проблемы Не, по большому счету это проблема автора ибо я себе найду другую библиотеку, а вот его библиотекой будет пользоваться меньшей людей. Недостаточно просто написать доку, хороший интерфейс должен способствовать правильному использованию и сводить к минимуму возможности его использовать неправильно. 0

Nishen 1352 / 851 / 365 Регистрация: 26.02.2015 Сообщений: 3,799
		1
	Пишем свой класс, спецификатор доступа protected 09.07.2015, 18:43. Показов 5095. Ответов 61 Метки нет (Все метки) Всем привет! Из книги Р. Лафоре относительно спецификатора доступа protected: Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected. Далее пишется следующее: Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private. Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 14:52	41
	Сообщение от ct0r Либо все время проверять дату на валидность и не допускать левых дат. Ну вообще-то достаточно проверять дату при вводе/задании. Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 14:58	42
	Сообщение от Avazart Ну вообще-то достаточно проверять дату при вводе/задании. Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего. Ну это все понятно. Только мне кажется, что ты говоришь о всем приложении в целом, а я о проектировании библиотечного класса, который не в курсе, проверяешь ты там снаружи свои данные, или уверен в их правильности, или еще что. PS где-то я уверен, что передаю верные данные. Где-то не уверен. И здесь правильный подход - проверять корректность в использующей класс части только там, где нужно. Этим и будут сохраняться инварианты класса и избегаться UB. А в классе оставить только ассерты и не пытаться сохранить инварианты любой ценой. 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	10.07.2015, 15:23	46
	Сообщение от ct0r То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске. мне не интересны дешовые понты. не пишите мне больше. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 15:42	48
	Сообщение от ct0r то либо оберни в свой Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализацию с проверками зачем мне мараться. Добавлено через 1 минуту Сообщение от ct0r Но изначально предоставлять класс со всеми проверками - не лучшая идея. Не лучшая идея допускать UB cо старта. Добавлено через 56 секунд Сообщение от ct0r Тот, кто его использует, обязан проверять, что он следует контракту используемого класса для того, чтобы получить гарантированное поведение. Тому кто использует срать, он хочет получить желаемое, а не UB. UB на то UB а не гарантированое повидение. Если вы изначально UB приравниваете/(включаете) к гарантированному поведению то грош вам цена как программисту. Понятно что есть некоторые упущения и "люфты" которые могут привести к UB при использовании библиотеки, но тем не менее не на каждом же шагу. 1

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 15:46	49
	Сообщение от Avazart Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализации зачем мне мараться. То есть для тебя читать документацию означает мараться? Ну ок Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как? Добавлено через 1 минуту Сообщение от Avazart Тому кто использует срать, он хочет получить желаемое, а не UB. UB на то UB а не гарантированое повидение. Если вы изначально UB приравниваете/(включаете) к гарантированному поведению то грош вам цена как программисту. Понятно что есть некоторые упущения и "люфты" которые могут привести к UB при использовании библиотеки, но тем не менее не на каждом же шагу. Оу, почитайте про DbC на досуге. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 16:05	51
	Сообщение от Avazart А при чем тут дока? Если кривая библиотека, то и получишь документацию к кривой библиотеке не более. Библиотека не кривая. Если ты ее используешь не так, как задумано авторами (как задумано - написано в документации) - это твои личные проблемы. Библиотека ведет себя в полном соответствии с документацией. Почему тогда она кривая? Или по твоей логике, если белье сушится в микроволновке как-то странно, то это микроволновка кривая? Или все-таки проблема в том, что ты не прочитал, как ей пользоваться? Сообщение от Avazart А с чего начинать со специализированных классов? С таким же успехом можно было уже и назвать std:air<> в котором члены класса открыты. Вы ведь сами изначально привели пример с датой изначально так? Везде есть контракт на вызов. И там, и там, тебе говорят, не вызывай, мол, такую-то функцию с такими-то данными, получишь фиг знает что! Добавлено через 5 минут PS Хочешь пользоваться микроволновкой, которая всегда перед нагревом целую минуту проверяет, положил ты туда еду или еще что? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 16:19	52
	Сообщение от ct0r но - написано в документации) - это твои личные проблемы. Библиотека ведет себя в полном соответствии с документацией. Почему тогда она кривая? Или по твоей логике, если белье сушится в микроволновке как-то странно, то это микроволновка кривая? Или все-таки проблема в том, что ты не прочитал, как ей пользоваться? Если микроволновка выглядит полностью как стиральная машинка то да виноват разработчик и тут дока не при чем ибо ошибка допущена уже при покупке "инструмента". Добавлено через 4 минуты Сообщение от ct0r PS Хочешь пользоваться микроволновкой, которая всегда перед нагревом целую минуту проверяет, положил ты туда еду или еще что? Тем не менее не плохо бы что бы микроволновка не допускала включение при открытой дверце. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 16:34	54
	Сообщение от Avazart Если микроволновка выглядит полностью как стиральная машинка то да виноват разработчик и тут дока не при чем ибо ошибка допущена уже при покупке "инструмента". Так кто все-таки виноват? Производитель или потребитель? А может в городе, в котором живет производитель, микроволновки выглядят как раз именно так, как у тебя стиральные машинки? Для того и существует документация - чтобы устранять непонимания между тем, кто производит, и тем, кто пользуется. Да и вообще это не наш случай. В нашем внешний вид практически один и тот же. Сообщение от Avazart Тем не менее не плохо бы что бы микроволновка не допускала включение при открытой дверце. Даже если будет минуту определять, открыта она или нет? А как насчет определения, не нагреется ли за такое время еда больше, чем хочет потребитель? Или меньше? Говорю же, каждая ситуация имеет свои специфические особенности, которые надо учитывать. Поэтому говорить, что например, всегда куча проверок - это хорошо - неправильно. Добавлено через 2 минуты Сообщение от Voivoid Не, по большому счету это проблема автора ибо я себе найду другую библиотеку, а вот его библиотекой будет пользоваться меньшей людей. Недостаточно просто написать доку, хороший интерфейс должен способствовать правильному использованию и сводить к минимуму возможности его использовать неправильно. Да, верно. Но DbC мало как влияет на внешний вид API. Просто в одном случае проверки спрятаны внутри, а в другом - их нет, и неправильное использование ведет к UB. И для того, чтобы определить, есть они или нет, все равно нужно читать доку. Логично постоянно задаваться вопросом - а что будет, если я передам неверные данные? И ответ надо искать в документации, а не фантазировать. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	10.07.2015, 17:06	55
	Сообщение от ct0r Так кто все-таки виноват? Вина потребителя лишь в том что он купил фиговый инструмент. Сообщение от ct0r А может в городе, в котором живет производитель, микроволновки выглядят как раз именно так, как у тебя стиральные машинки? Ну а если бы в рту росли грибы .... С таким подходом все можно довести до абсурда. Сообщение от ct0r Для того и существует документация - чтобы устранять непонимания между тем, кто производит, и тем, кто пользуется. К примеру, а если в моем городе не принято читать документацию? Сообщение от ct0r Даже если будет минуту определять, открыта она или нет? А как насчет определения, не нагреется ли за такое время еда больше, чем хочет потребитель? Или меньше? Говорю же, каждая ситуация имеет свои специфические особенности, которые надо учитывать. Поэтому говорить, что например, всегда куча проверок - это хорошо - неправильно. У вас микроволновка определяет минуту? В любом случае это лучше чем так позволяет работать с открытой дверцей, нарушая TБ. Я не говорил что нужно доводить все до абсурда и пихать проверки куда не нужно. 0

	11.07.2015, 03:12

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	10.07.2015, 17:36	56
	Avazart, вернемся к теме. Чел написал всем известную книгу: http://www.amazon.com/Large-Sc... 0201633620 http://stackoverflow.com/quest... are-design Его слова с аннотации к выступлению на CppCon14 (выделения мои): In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. Ты с ним не согласен? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	11.07.2015, 01:59	57
	Вопрос в том что ставить во главе безопасность или скорость, как по мне в большинстве случаем ставится во главе именно безопастность. С другой стороны спецификой именно С++ также являестся и эффективность/скорость. В общем баланс никто не отменял. В любом случае пользователю желательно предоставить безопастную библиоткеку точнее сказать библиотеку с безопасным видом/интерфейсом, в нутри которая конечно может содержать самые разные оптимизации от си кода до асм вставок. То что допустим STL не делает какие либо проверки и больший перевес в сторону скорости, так это "основопологающая" либа собственно которой отдельное место стандарте и посвещена не одна книга. Т.е готовы ли вы писать талмуды и "учить" людей как правильно использовать вашу библиотеку, вводить свои термины и понятия специфические для вашей либы? Нужна ли вам настолько производительность? Добавлено через 9 минут Не по теме: Сообщение от ct0r Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как? Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at(). Добавлено через 16 минут Сообщение от ct0r Avazart, вернемся к теме. Что касается изначальной темы и авторов книг: 41. Делайте данные-члены закрытыми (кроме случая агрегатов в стиле структур С) Резюме Данные-члены должны быть закрыты. Только в случае простейших типов в стиле структур языка С, объединяющих в единое целое набор значений, не претендующих на инкапсуляцию и не обеспечивающих поведение, делайте все данные-члены открытыми. Избегайте смешивания открытых и закрытых данных, что практически всегда говорит о бестолковом дизайне. Защищенные данные обладают всеми недостатками открытых данных, поскольку наличие защищенных данных означает, что абстракция разделяет ответственность за поддержание одного или нескольких инвариантов с неограниченным множеством кода — теперь это код существующих и будущих производных классов. Более того, любой код может читать и модифицировать защищенные данные так же легко, как и открытые — просто создав производный класс и используя его для доступа к данным. Герб Саттер, Андрей Александреску "Стандарты программирования на С++ 101 правило и рекомендация " http://bookscafe.net/read/satt... idp1948512 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	11.07.2015, 02:52	58
	Сообщение от Avazart В любом случае пользователю желательно предоставить безопастную библиоткеку точнее сказать библиотеку с безопасным видом/интерфейсом, в нутри которая конечно может содержать самые разные оптимизации от си кода до асм вставок. Желательно кому? А если пользователю ну очень важна скорость? Еще при проектировании либы разработчики примерно определяют, какой процент времени CPU целесообразно потратить на проверку предусловий. Сообщение от Avazart Т.е готовы ли вы писать талмуды и "учить" людей как правильно использовать вашу библиотеку, вводить свои термины и понятия специфические для вашей либы? Нужна ли вам настолько производительность? Ну а если нужна? Да и какие талмуды? Что именно должно документироваться, написано в вики https://en.wikipedia.org/wiki/Design_by_contract Сообщение от Avazart Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at(). Это только у вектора. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	11.07.2015, 03:00	59
	Сообщение от ct0r Желательно кому? А если пользователю ну очень важна скорость? Еще при проектировании либы разработчики примерно определяют, какой процент времени CPU целесообразно потратить на проверку предусловий. Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри". Сообщение от ct0r Да и какие талмуды? Что именно должно документироваться, Все что нестандартное, все что может вызвать ошибку итп, что бы пользователь не гадал и не лез в исходники что бы понять в чем и где ошибка. Разве всякие ассерты не являются проверками? Сообщение от ct0r Это только у вектора. Так на кой листу произвольный доступ. Если же итерируешь то самой сабой подразумевается проверка и валидность. Как в принципе и работа с массивами через указатели. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	11.07.2015, 03:12	60
	Сообщение от Avazart Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри". Двойной интерфейс как вариант. По сути это и есть готовая обертка - вызовы внутри будут делегироваться к коду без проверок. Сообщение от Avazart Все что нестандартное, все что может вызвать ошибку итп, что бы пользователь не гадал и не лез в исходники что бы понять в чем и где ошибка. В случае без проверок мы документируем, как правильно надо пользоваться, остальное - UB. В случае с проверками нам помимо этого нужно расписать, как либа сообщает об ошибках (исключения, коды ошибок, запись в лог, какие-нибудь Maybe монады) и какие именно ошибки в каком случае возвращаются. Кажется, что во втором варианте писать больше, разве нет? Сообщение от Avazart Так на кой листу произвольный доступ. Если же итерируешь то самой сабой подразумевается проверка и валидность. Как в принципе и работа с массивами через указатели. Ну просто итераторы - это такая фигня, которая используется алгоритмами для того, чтобы по максимуму абстрагироваться от типа контейнера. Или я не понял, что ты имел в виду. 0