Форум программистов, компьютерный форум CyberForum.ru

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

Восстановить пароль Регистрация
 
 
Рейтинг: Рейтинг темы: голосов - 11, средняя оценка - 4.64
Nishen
 Аватар для Nishen
171 / 77 / 28
Регистрация: 26.02.2015
Сообщений: 455
09.07.2015, 18:43     Пишем свой класс, спецификатор доступа protected #1
Всем привет!
Из книги Р. Лафоре относительно спецификатора доступа protected:
Таким образом, если вы пишете класс, который впоследствии будет использоваться как базовый класс при наследовании, то данные, к которым нужно будет иметь доступ, следует объявлять как protected.
Далее пишется следующее:
Существуют и недостатки использования спецификатора доступа protected... это делает члены, объявленные как protected, значительно менее защищенными, чем объявленные как private.
Возникает вопросы: так когда же стоит использовать protected? Как я могу знать, захочет ли кто-нибудь использовать мой класс, как базовый? И как не доиграться со спецификаторами доступа? Как быть, если я хочу использовать чужой класс, но поля класса закрыты спецификатором private?
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 14:52     Пишем свой класс, спецификатор доступа protected #41
Цитата Сообщение от ct0r Посмотреть сообщение
Либо все время проверять дату на валидность и не допускать левых дат.
Ну вообще-то достаточно проверять дату при вводе/задании.
Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего.
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 14:58     Пишем свой класс, спецификатор доступа protected #42
Цитата Сообщение от Avazart Посмотреть сообщение
Ну вообще-то достаточно проверять дату при вводе/задании.
Если же вы допустите некорректный ввод, то вы получите не предвиденные последствия (вообще это как бы банально и ежу понятно) которые вы потом уже никак не отловите и не обнаружите и в этом нет ничего хорошего.
Ну это все понятно. Только мне кажется, что ты говоришь о всем приложении в целом, а я о проектировании библиотечного класса, который не в курсе, проверяешь ты там снаружи свои данные, или уверен в их правильности, или еще что.

PS где-то я уверен, что передаю верные данные. Где-то не уверен. И здесь правильный подход - проверять корректность в использующей класс части только там, где нужно. Этим и будут сохраняться инварианты класса и избегаться UB. А в классе оставить только ассерты и не пытаться сохранить инварианты любой ценой.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 15:03     Пишем свой класс, спецификатор доступа protected #43
К примеру

C++
1
2
3
4
5
6
7
8
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
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 15:12     Пишем свой класс, спецификатор доступа protected #44
Цитата Сообщение от Avazart Посмотреть сообщение
Если не делать валидацию при вводе то вы никогда не поймете почему days получился некорректном, ибо дофига варинтов:
Само собой. Но проверки - это не обязательно ответственность именно класса.

Цитата Сообщение от Avazart Посмотреть сообщение
А библиотечные классы не строятся один на другом?
Какая разница? Всегда есть используемый класс и использующий.

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

Добавлено через 3 минуты
Совсем хорошо, если еще негативные тесты есть.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 15:20     Пишем свой класс, спецификатор доступа protected #45
Цитата Сообщение от ct0r Посмотреть сообщение
Какая разница? Всегда есть используемый класс и использующий.
Да любой класс используемый, вопрос уровня. Для того и пишут классы- для возможности повторного использования, а не копипаста кода. Вот как раз отсутствие проверок и делает код непригодным к повторному использованию ибо "человек" должен слишком много знать об этом кривом классе и слишком много сделать проверок руками... и возможно окажется что легче будет писать с нуля нежели использовать этот класс.

Добавлено через 2 минуты
Цитата Сообщение от ct0r Посмотреть сообщение
Само собой. Но проверки - это не обязательно ответственность именно класса.
А кого тогда эта ответственность?
Класс должен отвечать за то что ему поручают, т.е за то с чем его ассоциируют,
Класс "дата" не должен хранить класс "строку" ( как в моем примере: from.setDate(" .... "); ) он должен хранить именно дату, а не что иное.
hoggy
5225 / 2116 / 403
Регистрация: 15.11.2014
Сообщений: 4,800
Завершенные тесты: 1
10.07.2015, 15:23     Пишем свой класс, спецификатор доступа protected #46
Цитата Сообщение от ct0r Посмотреть сообщение
То есть вы даже Джоэла Сполски не читали? А гуглить умеете? Первая ссылка в поиске.
мне не интересны дешовые понты.
не пишите мне больше.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 15:33     Пишем свой класс, спецификатор доступа protected #47
Цитата Сообщение от Avazart Посмотреть сообщение
Да любой класс используемый, вопрос уровня. Для того и пишут классы- для возможности повторного использования, а не копипаста кода. Вот как раз отсутствие проверок и делает код непригодным к повторному использованию ибо "человек" должен слишком много знать об этом кривом классе и слишком много сделать проверок руками... и возможно окажется что легче будет писать с нуля нежели использовать этот класс.
Вообще не вижу проблем. Если у тебя такая ситуация, что на каждый чих что-то надо проверять, то либо оберни в свой, в котором будут проверки, либо воспользуйся уже такой готовой оберткой. Но изначально предоставлять класс со всеми проверками - не лучшая идея.

Цитата Сообщение от Avazart Посмотреть сообщение
А кого тогда эта ответственность?
Тот, кто его использует, обязан проверять, что он следует контракту используемого класса для того, чтобы получить гарантированное поведение.

Добавлено через 3 минуты
Цитата Сообщение от hoggy Посмотреть сообщение
мне не интересны дешовые понты.
не пишите мне больше.
Хорошо. Не вижу смысла вам писать, раз уж сами не можете потратить минуту на поиск информации. Я в няньки не нанимался.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 15:42     Пишем свой класс, спецификатор доступа protected #48
Цитата Сообщение от ct0r Посмотреть сообщение
то либо оберни в свой
Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализацию с проверками зачем мне мараться.

Добавлено через 1 минуту
Цитата Сообщение от ct0r Посмотреть сообщение
Но изначально предоставлять класс со всеми проверками - не лучшая идея.
Не лучшая идея допускать UB cо старта.

Добавлено через 56 секунд
Цитата Сообщение от ct0r Посмотреть сообщение
Тот, кто его использует, обязан проверять, что он следует контракту используемого класса для того, чтобы получить гарантированное поведение.
Тому кто использует срать, он хочет получить желаемое, а не UB.
UB на то UB а не гарантированое повидение.

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

Понятно что есть некоторые упущения и "люфты" которые могут привести к UB при использовании библиотеки, но тем не менее не на каждом же шагу.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 15:46     Пишем свой класс, спецификатор доступа protected #49
Цитата Сообщение от Avazart Посмотреть сообщение
Зачем? Я так вряд ли поступлю... скорее я выкину тот класс и напишу свою реализации зачем мне мараться.
То есть для тебя читать документацию означает мараться? Ну ок Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?

Добавлено через 1 минуту
Цитата Сообщение от Avazart Посмотреть сообщение
Тому кто использует срать, он хочет получить желаемое, а не UB.
UB на то UB а не гарантированое повидение.
Если вы изначально UB приравниваете/(включаете) к гарантированному поведению то грош вам цена как программисту.
Понятно что есть некоторые упущения и "люфты" которые могут привести к UB при использовании библиотеки, но тем не менее не на каждом же шагу.
Оу, почитайте про DbC на досуге.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 15:49     Пишем свой класс, спецификатор доступа protected #50
А при чем тут дока? Если кривая библиотека, то и получишь документацию к кривой библиотеке не более.

Цитата Сообщение от ct0r Посмотреть сообщение
Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?
А с чего начинать со специализированных классов?
С таким же успехом можно было уже и назвать std::pair<> в котором члены класса открыты.

Вы ведь сами изначально привели пример с датой изначально так?
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 16:05     Пишем свой класс, спецификатор доступа protected #51
Цитата Сообщение от Avazart Посмотреть сообщение
А при чем тут дока? Если кривая библиотека, то и получишь документацию к кривой библиотеке не более.
Библиотека не кривая. Если ты ее используешь не так, как задумано авторами (как задумано - написано в документации) - это твои личные проблемы. Библиотека ведет себя в полном соответствии с документацией. Почему тогда она кривая? Или по твоей логике, если белье сушится в микроволновке как-то странно, то это микроволновка кривая? Или все-таки проблема в том, что ты не прочитал, как ей пользоваться?

Цитата Сообщение от Avazart Посмотреть сообщение
А с чего начинать со специализированных классов?
С таким же успехом можно было уже и назвать std:air<> в котором члены класса открыты.
Вы ведь сами изначально привели пример с датой изначально так?
Везде есть контракт на вызов. И там, и там, тебе говорят, не вызывай, мол, такую-то функцию с такими-то данными, получишь фиг знает что!

Добавлено через 5 минут
PS Хочешь пользоваться микроволновкой, которая всегда перед нагревом целую минуту проверяет, положил ты туда еду или еще что?
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 16:19     Пишем свой класс, спецификатор доступа protected #52
Цитата Сообщение от ct0r Посмотреть сообщение
но - написано в документации) - это твои личные проблемы. Библиотека ведет себя в полном соответствии с документацией. Почему тогда она кривая? Или по твоей логике, если белье сушится в микроволновке как-то странно, то это микроволновка кривая? Или все-таки проблема в том, что ты не прочитал, как ей пользоваться?
Если микроволновка выглядит полностью как стиральная машинка то да виноват разработчик и тут дока не при чем ибо ошибка допущена уже при покупке "инструмента".

Добавлено через 4 минуты
Цитата Сообщение от ct0r Посмотреть сообщение
PS Хочешь пользоваться микроволновкой, которая всегда перед нагревом целую минуту проверяет, положил ты туда еду или еще что?
Тем не менее не плохо бы что бы микроволновка не допускала включение при открытой дверце.
Voivoid
 Аватар для Voivoid
580 / 256 / 12
Регистрация: 31.03.2013
Сообщений: 1,283
10.07.2015, 16:28     Пишем свой класс, спецификатор доступа protected #53
Цитата Сообщение от ct0r Посмотреть сообщение
Библиотека не кривая. Если ты ее используешь не так, как задумано авторами (как задумано - написано в документации) - это твои личные проблемы
Не, по большому счету это проблема автора ибо я себе найду другую библиотеку, а вот его библиотекой будет пользоваться меньшей людей. Недостаточно просто написать доку, хороший интерфейс должен способствовать правильному использованию и сводить к минимуму возможности его использовать неправильно.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 16:34     Пишем свой класс, спецификатор доступа protected #54
Цитата Сообщение от Avazart Посмотреть сообщение
Если микроволновка выглядит полностью как стиральная машинка то да виноват разработчик и тут дока не при чем ибо ошибка допущена уже при покупке "инструмента".
Так кто все-таки виноват? Производитель или потребитель? А может в городе, в котором живет производитель, микроволновки выглядят как раз именно так, как у тебя стиральные машинки? Для того и существует документация - чтобы устранять непонимания между тем, кто производит, и тем, кто пользуется. Да и вообще это не наш случай. В нашем внешний вид практически один и тот же.

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

Добавлено через 2 минуты
Цитата Сообщение от Voivoid Посмотреть сообщение
Не, по большому счету это проблема автора ибо я себе найду другую библиотеку, а вот его библиотекой будет пользоваться меньшей людей. Недостаточно просто написать доку, хороший интерфейс должен способствовать правильному использованию и сводить к минимуму возможности его использовать неправильно.
Да, верно. Но DbC мало как влияет на внешний вид API. Просто в одном случае проверки спрятаны внутри, а в другом - их нет, и неправильное использование ведет к UB. И для того, чтобы определить, есть они или нет, все равно нужно читать доку. Логично постоянно задаваться вопросом - а что будет, если я передам неверные данные? И ответ надо искать в документации, а не фантазировать.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
10.07.2015, 17:06     Пишем свой класс, спецификатор доступа protected #55
Цитата Сообщение от ct0r Посмотреть сообщение
Так кто все-таки виноват?
Вина потребителя лишь в том что он купил фиговый инструмент.

Цитата Сообщение от ct0r Посмотреть сообщение
А может в городе, в котором живет производитель, микроволновки выглядят как раз именно так, как у тебя стиральные машинки?
Ну а если бы в рту росли грибы ....
С таким подходом все можно довести до абсурда.

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


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

Я не говорил что нужно доводить все до абсурда и пихать проверки куда не нужно.
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
10.07.2015, 17:36     Пишем свой класс, спецификатор доступа protected #56
Avazart, вернемся к теме.

Чел написал всем известную книгу:
http://www.amazon.com/Large-Scale-So.../dp/0201633620
http://stackoverflow.com/questions/1...oftware-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
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
11.07.2015, 01:59     Пишем свой класс, спецификатор доступа protected #57
Вопрос в том что ставить во главе безопасность или скорость, как по мне в большинстве случаем ставится во главе именно безопастность. С другой стороны спецификой именно С++ также являестся и эффективность/скорость. В общем баланс никто не отменял.

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

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

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

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

Не по теме:

Цитата Сообщение от ct0r Посмотреть сообщение
Может с итераторов начнешь? А то класс итератора при разыменовании не проверяет, конечный он или нет. Там UB получается. Ну так как?
Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at().



Добавлено через 16 минут
Цитата Сообщение от ct0r Посмотреть сообщение
Avazart, вернемся к теме.
Что касается изначальной темы и авторов книг:

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

Резюме
Данные-члены должны быть закрыты. Только в случае простейших типов в стиле структур языка С, объединяющих в единое целое набор значений, не претендующих на инкапсуляцию и не обеспечивающих поведение, делайте все данные-члены открытыми. Избегайте смешивания открытых и закрытых данных, что практически всегда говорит о бестолковом дизайне.
Защищенные данные обладают всеми недостатками открытых данных, поскольку наличие защищенных данных означает, что абстракция разделяет ответственность за поддержание одного или нескольких инвариантов с неограниченным множеством кода — теперь это код существующих и будущих производных классов. Более того, любой код может читать и модифицировать защищенные данные так же легко, как и открытые — просто создав производный класс и используя его для доступа к данным.
Герб Саттер, Андрей Александреску "Стандарты программирования на С++ 101 правило и рекомендация "

http://bookscafe.net/read/satter_ger...TOC_idp1948512
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
11.07.2015, 02:52     Пишем свой класс, спецификатор доступа protected #58
Цитата Сообщение от Avazart Посмотреть сообщение
В любом случае пользователю желательно предоставить безопастную библиоткеку точнее сказать библиотеку с безопасным видом/интерфейсом, в нутри которая конечно может содержать самые разные оптимизации от си кода до асм вставок.
Желательно кому? А если пользователю ну очень важна скорость? Еще при проектировании либы разработчики примерно определяют, какой процент времени CPU целесообразно потратить на проверку предусловий.

Цитата Сообщение от Avazart Посмотреть сообщение
Т.е готовы ли вы писать талмуды и "учить" людей как правильно использовать вашу библиотеку, вводить свои термины и понятия специфические для вашей либы? Нужна ли вам настолько производительность?
Ну а если нужна? Да и какие талмуды? Что именно должно документироваться, написано в вики https://en.wikipedia.org/wiki/Design_by_contract

Цитата Сообщение от Avazart Посмотреть сообщение
Кстати все же для этого есть алтернативный интерфейс через индексы и метод .at().
Это только у вектора.
Avazart
 Аватар для Avazart
6897 / 5137 / 252
Регистрация: 10.12.2010
Сообщений: 22,578
Записей в блоге: 17
11.07.2015, 03:00     Пишем свой класс, спецификатор доступа protected #59
Цитата Сообщение от ct0r Посмотреть сообщение
Желательно кому? А если пользователю ну очень важна скорость? Еще при проектировании либы разработчики примерно определяют, какой процент времени CPU целесообразно потратить на проверку предусловий.
Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри".

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

Цитата Сообщение от ct0r Посмотреть сообщение
Это только у вектора.
Так на кой листу произвольный доступ. Если же итерируешь то самой сабой подразумевается проверка и валидность.
Как в принципе и работа с массивами через указатели.
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
11.07.2015, 03:12     Пишем свой класс, спецификатор доступа protected
Еще ссылки по теме:

Спецификатор доступа и виртуальные функции C++
C++ пишем свой троян с нуля
Пишем свой чекер C++

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
ct0r
C++/Haskell
 Аватар для ct0r
1549 / 568 / 39
Регистрация: 19.08.2012
Сообщений: 1,174
Завершенные тесты: 1
11.07.2015, 03:12     Пишем свой класс, спецификатор доступа protected #60
Цитата Сообщение от Avazart Посмотреть сообщение
Двойной интерфейс (безопасный/небезопасный), оптимизация "внутри".
Двойной интерфейс как вариант. По сути это и есть готовая обертка - вызовы внутри будут делегироваться к коду без проверок.

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

Цитата Сообщение от Avazart Посмотреть сообщение
Так на кой листу произвольный доступ. Если же итерируешь то самой сабой подразумевается проверка и валидность.
Как в принципе и работа с массивами через указатели.
Ну просто итераторы - это такая фигня, которая используется алгоритмами для того, чтобы по максимуму абстрагироваться от типа контейнера. Или я не понял, что ты имел в виду.
Yandex
Объявления
11.07.2015, 03:12     Пишем свой класс, спецификатор доступа protected
Ответ Создать тему
Опции темы

Текущее время: 23:59. Часовой пояс GMT +3.
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Рейтинг@Mail.ru