Кто отвечает за корректность аргументов функции?

Вопрос к знатокам стандарта или просто ведующим.

В языке c за корректность аргументов обычно отвечает вызывающая сторона.

Т.е. если ты вызываешь printf("%d", some_int) и подставляешь туда нечто не int,
то это твои проблемы потом удивляться, недоумевать или возмущаться на некорректный вывод или уход в даун.

А с++ какая практика?

1

Сообщение от Renji Чем лучше код обмазан assert-ами, тем быстрее такие ошибки всплывут.

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

Сообщение от jugu Это не имеет смысла, т.к. нет собеседника

Цитата из Жванецкого точна. Если нет аргументов, нет смысла их искать. А разговоры о "шаг-влево шаг-вправо", это о пользе бедных. Мы тут знаем, что одна точка может изменить судьбу, а уж шажки, шаги или прыжки - совершенно излишни. Но да. Для любителей попрыгать хорошая защита, это благо.

0

Сообщение от jugu пример из STL вроде я привел (см. пару постов выше). И пояснил, почему он хорош.

Плохой пример)

Во-первых, реальная реализация содержит 100500 дебажных проверок.
А вас послушать - она вообще в проверках не нуждается.

А во-вторых, даже несмотря на обилие проверочного кода,
функция все равно ненадежная.

Она не обеспечивает 100% инвариант.
И уязвима к переполнению буфера.

Приведенный вами пример - пример хрупкого дизайна.

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

Сообщение от IGPIGP тут тоже вместо аргументов пытался оценивать оппонента. А потом изумлялся : "Что такое хамство?"

Вряд ли)
Вряд ли hoggy станет изумляться человеческому невежеству.

1

Сообщение от eva2326 Вряд ли) Вряд ли hoggy станет изумляться человеческому невежеству.

И вы туда же. Я сказал о том, что assert отключаемы. В ответ получил обвинения в том, что я "не в теме", вместо аргументов. Там не было изумления. Что бы далеко не ходить, для новичковского уровня:
NDEBUG
А переходы на личности там где нет нормальных слов и аргументов, - это и есть землепашеская (Хам - крестьянин) этика.

0

Сообщение от IGPIGP Я сказал о том, что assert отключаемы. В ответ получил обвинения в том, что я "не в теме", вместо аргументов

Обвинения?
Вас никто не обвиняет.
Потому что не зачем.
Потому что в конечном счете всем просто наплевать.

Аргумент простой: вы не понимаете, зачем нужны ассерты.
Ваше поведение, ваши тезисы сразу намекнут любому мало-мальски практикующему программисту,
Что вы - просто очередной любитель порассуждать о том, в чем вы не разбираетесь.

Сообщение от IGPIGP А переходы на личности там где нет нормальных слов и аргументов, - это и есть землепашеская (Хам - крестьянин) этика.

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

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

Хамить может сын отцу.
Или учитель учителю.
Или подчиненный начальнику.

Человек, который считает, что ему хамят - либо невежда,
либо считает себя выше других.

Никакой "землепашской этики" не существует.

0

Сообщение от eva2326 Аргумент простой: вы не понимаете, зачем нужны ассерты.

Объясните в двух словах.
eva2326, можно назвать человека тупым или невеждой. А можно объяснить, что поскольку в С (процедурный стиль) проверка - дело вызывающей стороны (как правило - подчёркиваю), а С быстрее С++ - медицинский факт (как правило быстрее, - тоже для тех кто в танке), то объектная деориентация фрагмента кода (переход к процедурному стилю) может ускорить выполнение. Ценой будет отказ от преимуществ ООП в данном фрагменте. Инвариант не бесплатная штука.
Это без конкретных примеров отсутствия проверок в функциях стандартной библиотеки и разжевывания. Это из совсем общих соображений.
Точно так же вы можете объяснить мне, что по вашему, я понимаю неверно относительно assert в контексте вопроса темы и моих высказываний в ней. А можете перейти к личным оценкам. Посмотрите цитату Жванецкого. Он там не о vector::at(size_t). Он о хамстве. И если о нём, то считать дворян императорской России "погремушниками", ярчайшее к ним не уважение. Тот термин относился именно к дворянам (себе подобным) и служил началом приглашения на дуэль. Лишь ничтожество из дворян, стало бы обвинять холопа или его лошадь в хамском поведении. Я не касаюсь здесь армейской практики, конечно. Тут вы всё не верно толкуете, сударыня.

0

IGPIGP, возможно, этот стих тоже ставит цитирующего в положение считающего себя выше других, но все же Мф. 7:6. Я прекрасно понимаю вашу мотивацию к интересной беседе, но когда она превращается в тупое хамство, то имхо наивно рассчитывать на адекватность и здравомыслие собеседников В этой теме действительно все понятно, но несмотря на это имхо не стоит посягать на заблуждения оппонентов, они им дороги как память (С)

1

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

_Ivana, я думаю, вы говорите обо мне. Приведите пример. Тупого/лощёного - любого, хамства с моей стороны.
Андрей, я же не оценивал ни кого. Просто аргументировал. В ответ, я получаю "невежда" и без аргументов.
Это не интересно. К сожалению, это обыденность.
_Ivana, скажите лучше вот что. Вот у оператора индексирования вектора нет проверки выхода за пределы. Он не блюдёт инвариант и возлагает это на вызывающую сторону. Метод at - тоже член, но вариант с внутренней проверкой.
Интересно уже не это. Интересно то, что человек, который защищает парадигму "всё защищено изнутри", говорит:

Сообщение от hoggy а вот зачем в std::vector этот метод завезли - это для меня вопрос.

Это же он про at говорит. О методе который он должен защищать!
То есть, левая часть мозга не ведает о том, что говорит правая? Я думаю, она вообще не затрудняется. Важна только вера в свою правоту и отсюда зрение переворачивающее всё с ног на голову. Не знаю, что ещё добавить.

0

ЗЫ ну и что касается сабжевого вопроса, то мой первый вариант ответа модератору не понравился, поэтому вношу правку: Мф. 10:29 (в вольном переводе) - ни один аргумент не попадет в функцию без воли Того, кто контролирует передачу аргументов функции, у Него и аргументы и функции все сочтены,

Добавлено через 1 минуту
IGPIGP, я разумеется не про ваше хамство (его и не было), а про хамство в ваш адрес, начатое хоггем и поддержанное некоторыми другими.

1

Сообщение от _Ivana Мф. 10:29 (в вольном переводе) - ни один аргумент не попадет в функцию без воли Того, кто контролирует передачу аргументов функции, у Него и аргументы и функции все сочтены,

Воистину.

Сообщение от _Ivana IGPIGP, я разумеется не про ваше хамство (его и не было), а про хамство в ваш адрес, начатое хоггем и поддержанное некоторыми другими.

Хух... Спасибо) Ваше слово для меня имеет значение. Спасибо.

0

Сообщение от _Ivana а про хамство в ваш адрес, начатое хоггем

где ты увидел хамство?
попробуй аргументировать.

дабы не прослыть голословной балаболкой.

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

Сообщение от IGPIGP Это же он про at говорит. О методе который он должен защищать!

знаешь в чем твоя проблема, гип-гип?

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

ты вообще не знаешь, какие бывают классы ошибок,
и как с ними общепринято работать на плюсах.

если бы знал, тогда понимал бы,
почему метод at - нелогичен, и бесполезен.

что примечательно, ни разу ещё не видел ни в одном проекте,
что бы кто-то использовал at.

0

Сообщение от hoggy знаешь в чем твоя проблема

Знаете в чём ваша проблема? Вы ищете самореализацию в том чтобы объявить кому-то, что он чего-то не знает.
То что вы слабоваты в логике, - не проблема. Я видел синьоров и похуже.
Я не буду перечислять чего вы не знаете. Хочу остановиться на том что утверждая что

Сообщение от hoggy метод at - нелогичен, и бесполезен.

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

Сообщение от hoggy нелогичен, и бесполезен.

И вы это говорите отстаивая точку зрения о инварианте, инкапсуляции, проверках на вызываемой стороне. О том, что vector - центр stl и там нет ни чего случайного я помолчу.
И я уже писал об этом. Но на вас это не действует. Ну же hoggy, напрягитесь. А что касается ваших манер, то я устал от них.

Сообщение от eva2326 Потому что в конечном счете всем просто наплевать.

Не-а. Не судите по себе. Хороших людей как и всего хорошего всегда не много, но они тут есть.

0

Сообщение от IGPIGP Вот у оператора индексирования вектора нет проверки выхода за пределы. Он не блюдёт инвариант и возлагает это на вызывающую сторону.

Неужели?

Сообщение от IGPIGP Не-а. Не судите по себе. Хороших людей как и всего хорошего всегда не много, но они тут есть.

Я никогда не сужу по себе.
Однако, я смотрю на мир без розовых очков.

Хороших людей всегда много.
Но что с того?
Завтра вы умрете, сколько из этих хороших людей вспомнит о вас через месяц?

Вы вообще помните с чего начался этот диалог?
Вас никто не обвинял, потому что это никому не нужно.

0

Сообщение от IGPIGP Чем лучше код обмазан assert-ами, тем быстрее такие ошибки всплывут.

Совершенно верно. Плюс еще всякие if constexpr, enable_if, а далее - requires. Проверок вызываемая сторона делает много (часть из них явные, часть скрытые). Таким образом, по сути исходного вопроса можно сказать, что практика в современном С++ - делать проверки по максимуму на вызываемой стороне (причем чем раньше, тем лучше, т.е. на этапе компиляции). О чем я изначально и писал.

0

Сообщение от IGPIGP И вы это говорите отстаивая точку зрения о инварианте, инкапсуляции, проверках на вызываемой стороне.

Здесь как раз никакого противоречия, потому как у at проблемы не с инвариантами, а с дизайном. Когда у меня срабатывает assert в дебаг-сборке, я вываливаюсь в отладчик, где вижу подробные данные о состоянии программы. Когда у меня в релиз-сборке вылетит std::out_of_range... куда я вывалюсь, в лог-файл с одной строчкой "Ops... std::out_of_range occurred"? Ну и толку мне с этого?

Вместо этого метод мог бы:
1) Вызывать функтор формирующий отчет об ошибке, состоящий минимум из трассировки стека.
2) При выходе за границы массива, возвращать значение по умолчанию. Нужна ссылка? Окей, пусть возвращает ссылку на static объект.
Вот это уже выглядит несколько более приличным подходом.

0

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

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

моё мнение дословно:

Сообщение от rams В языке c за корректность аргументов обычно отвечает вызывающая сторона.

Сообщение от hoggy обе стороны. и это не зависит от языка.

Сообщение от IGPIGP а метод пытающийся соблюсти инвариант

тебе бы тоже было бы очевидно, что at - ненужен,
если бы ты понимал для чего нужны ассерты.

Сообщение от IGPIGP А что касается ваших манер, то я устал от них.

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

нет беды в том, что человек что-то не знает.

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

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

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

Сообщение от Renji 2) При выходе за границы массива, возвращать значение по умолчанию. Нужна ссылка? Окей, пусть возвращает ссылку на static объект.

действительно.
зачем кому то знать, что у нас тут программная ошибка.
замаскируем баг.
пускай ещё полгода с собаками ищут.

0

Сообщение от eva2326 Я никогда не сужу по себе.

Это не нормально. Человек есть мерило всего. Это древняя истина. Однако качество результата измерения зависит от качества инструмента и методики измерения. Я как и любой нормальный человек мерю собой (своими мыслями, ощущениями, эмоциями). Но вывода вроде : "Всем плевать" не получал и не получу. Однако нет смысла в таких выражениях продолжать.

Сообщение от jugu Совершенно верно. Плюс еще всякие if constexpr, enable_if, а далее - requires. Проверок вызываемая сторона делает много (часть из них явные, часть скрытые). Таким образом, по сути исходного вопроса можно сказать, что практика в современном С++ - делать проверки по максимуму на вызываемой стороне (причем чем раньше, тем лучше, т.е. на этапе компиляции).

С проверками в дебаге и проверками времени компиляции в релиизе (не всегда применимыми к сожалению) я не спорил. Я говорил о том, что ассерты отключаемы, а компайл-тайм проверки не генерируют кода и подавно. Поэтому код на вызываемой стороне не генерируется. А проверки инварианта в классах генерируют код (обычно). Это разве сравнимо? Что касается того о чём вы сказали, нет и не было возражений.

Сообщение от Renji Здесь как раз никакого противоречия, потому как у at проблемы не с инвариантами, а с дизайном.

Разработчикам stl - минус. Они бедолаги искали компромисс, "что бы как-то хрюкнуть но не тормозить вконец", а такие компромиссы не найдут благодарных сердец в массовых количествах. Се ля ви.
А у оператора индексирования вообще нет проверки. Как уже было озвучено at что у вектора, что у std::string - приблуда и используется редко. Я думаю, что так дело обстоит не только в аутсорсинговых дешёвых проектах. Но факт есть факт.
Но выходит, что практика C++ - использовать оператор [] без проверки в рантайме или с проверкой на вызывающей стороне. Именно это я и хотел сказать. Причём, то что at - плохо сделан (я так не думаю, на самом деле), мне в этом споре на руку. Он проверяет именно на вызываемой стороне и им не хотят пользоваться. А пользуются оператором индекса. Это практика.
Вообще, я не призывал отказываться от инварианта и проверок на вызываемой стороне. Если перечитать, то видно, что я говорил о том, что нет железного правила или пункта стандарта возлагающего ответственность на вызываемую сторону. И тот шум, который тут длится уже кучу постов, - нормальная практика из темы в тему. Что тут можно поделать?

0

Сообщение от hoggy действительно. зачем кому то знать, что у нас тут программная ошибка.

Может, это не ошибка, а так и задумано.
Собственно, Perl действует именно так, как я описал - при выходе за границы массива, подсовывает undef объект.

0

Сообщение от hoggy это ты с какого то перепугу решил, что оператор индексирования возлагает ответственность на вызывающую сторону.

hoggy, этот оператор это функция и он не делает проверки на своей стороне. В отличие от "плохого" at. И как мне ещё это объяснить? У меня нет перепугу и я не понимаю, почему у вас на языке такого рода вещи. Впрочем я не психолог и не собираюсь разбираться в ваших проблемах. Жалею, что стал это обсуждать, когда вы стали озвучивать мои, с вашей точки зрения, проблемы. В вас умер прсихоаналитик. Или ещё не умер?

0

Сообщение от Renji Может, это не ошибка, а так и задумано.

ты методы не перепутал?
то, что ты сейчас показал - это метод find
at - кидающийся исключениями,
агрессивный брат близнец operator[]

у них одинаковое предназначение:
получить доступ к элементу по индексу.

и одинаковый дизайн - индекс должен быть валидным.

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

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

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

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

Сообщение от Renji Собственно, Perl

неудачник, который прозябает где-то на задворках.

откуда такая манера:
вот в языке Х сделано через жопу.
давайте на плюсах также будем?

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

Сообщение от IGPIGP этот оператор это функция и он не делает проверки на своей стороне.

Сообщение от IGPIGP Впрочем я не психолог

а если был бы психологом, тогда бы знал,
что когда человек отрицает очевидную реальность
(тебе уже даже скриншоп показали в #52),
и продолжает тупить,
то это - шиза,
или психоз.

но я не психолог, и думаю, что это просто банальная тупость.

0

Сообщение от eva2326 Сообщение от IGPIGP Вот у оператора индексирования вектора нет проверки выхода за пределы. Он не блюдёт инвариант и возлагает это на вызывающую сторону. Неужели?

Тоже аргумент. Кто-то еще пользуется MS реализацией стандартной библиотеки.
В случае libstdc++ из gcc или libc++ из llvm - всё печальнее. Ассертов нет и, судя по всему, не предвидится.
А нужен ли этот Ассерт - вопрос, действительно спорный, и как сказал IGPIGP - холиварный.

1