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

@rams · Регистрация: 04.04.2012

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

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

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

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

@hoggy · 22.07.2019, 23:27

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

Вызывающая сторона - внешний мир. И она должна знать о функции

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

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

И всё же, решать разработчику, что ему выбрать.

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

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

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

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

хамите сударь.

ты вообще знаешь, что такое хамство?

IGPIGP · 22.07.2019, 23:28

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

Ну и на фига

rams, я согласен по духу, но

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

почти на 100%

это к сожалению многовато. Однако, тема холиварна. Она покажет новичкам в очередной раз, что можно быть неплохим технарём и слабо анализировать. Я тут и себя имею ввиду.
rams, вот простой пример. std::vector не отслеживает границ в операторе индексирования, но имеет метод at(size_t)
https://ru.cppreference.com/w/... /vector/at
где такая проверка производится (за отдельную плату). А решать, платить или нет - пользователю. Об этом я и говорю. Проверять перед вызовом, труднее, но можно сэкономить общее время выполнения. Вы думаете данный пример, новость для присутствующих? Нет. Но смотреть и видеть, - не одно и то же самое.

@hoggy · 22.07.2019, 23:35

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

if(min > max) ...?//Ну и на фига

почему у тебя min и max местами перепутались?

почему такое вообще могло произойти?
либо программная ошибка где-то в алгоритмах.
либо человеческий фактор (кто-то налажал, напутал, etc)

значит должен стоять assert(min <= max);

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

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

std::vector не отслеживает границ в операторе индексирования,

в любой вменяемой реализации (msvc, например) там стоит assert.

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

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

at(size_t)

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

IGPIGP · 22.07.2019, 23:36

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

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

Скромничаете. У вас гораздо больше вопросов, но мне это уже не интересно.

@rams · 22.07.2019, 23:47 **[ТС]**

int getRand(int min, int max){
if(min > max) ...?//Ну и на фига
if(min > 0)
if(max >0)
if(max <= MAX)
if
if
}

or

int rnd = getRand(-1,1);//boom this function not working, required another function or overload

@_Ivana · 22.07.2019, 23:48

Ответ имхо очевиден. Путин.

IGPIGP · 23.07.2019, 00:21

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

Ответ имхо очевиден. Путин.

Не похоже. Хотя, - с какой стороны посмотреть...

@Renji · 23.07.2019, 01:53

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

if(min > max) ...?//Ну и на фига

Иначе все эти if/assert будут не в одном getRand, а во всех точках где getRand вызывается.

@rams · 23.07.2019, 04:20 **[ТС]**

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

Иначе все эти if/assert будут не в одном getRand, а во всех точках где getRand вызывается.

А вы типа не знаете какие данные будете в функцию передавать и вобще чего в от нее хотите

IGPIGP · 23.07.2019, 09:24

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

Иначе все эти if/assert будут не в одном getRand, а во всех точках где getRand вызывается.

На каждый вызов, это будет свой набор. И он, что интересно, будет разный, так как в разных точках вызова аргументы порождаются по разному. Могут быть и такие где, всё или часть условий уже проверено по причинам не связанным с данным конкретным вызовом или гарантировано самим алгоритмом порождения аргументов.
Это сложно и не надёжно в по мере возрастания сложности, но это путь к повышению скорости. Где-то оправдано, а где-то нет.
Проверки в самой функции гарантируют полный пакет в каждом вызове.
Хорошо защищённый код похож на танковый полк. Мощно и непробиваемо. У нас споры тоже что-то из этого напоминают. В каждом танке - светлая голова. Иногда снаружи. Танкист блондин, - идеальный воин.

@jugu · 23.07.2019, 09:25

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

Где это требование изложено?

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

IGPIGP · 23.07.2019, 09:29

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

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

Я говорю о стандарте и документации. Что касается фундаментальных книг, будет уместно привести примеры, тем не менее. Это хороший способ убедиться в том, что фундамент не у всех отраслей человеческого знания, добротен.
И всё же.
Давайте так: источник, цитата, контекст. Интересно увидеть.

@jugu · 23.07.2019, 09:51

Вспомним функции WinAPI. Еще со времен Юрского периода у многих из них возвращаемым значением является HRESULT, который в закодированном виде представляет статус выполненной операции. По его значению можно понять, что произошло и что было не так с аргументами. При всём потоке кала с сторону Windows это ИМХО хороший стиль написания функций.

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

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

Я говорю о стандарте и документации.

В стандарте таких требований нет. У стандарта иные задачи.

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

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

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

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

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

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

Давайте так: источник, цитата, контекст. Интересно увидеть.

То есть вас убедит, если некий академик Иванов И.И. или профессор Swith S.S. давал такие рекомендации?

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

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

int getRand(int min, int max){
if(min > max) ...?//Ну и на фига
}

В этой функции как раз никакой проверки не надо. Идеальная интерфейс! Эх, если б все функции так можно было писать...
Кстати, в STL многие функции имеют именно такой интерфейс (функция связана с окружением по данным и по формату параметров), что гарантирует корректность аргументов и не требует проверки. В качестве примера приведем шаблон копирования:

C++
1
2
3
4
5
6
7
8
9
template<class InputIterator, class OutputIterator>
  OutputIterator copy (InputIterator first, InputIterator last, OutputIterator result)
{
  while (first!=last) {
    *result = *first;
    ++result; ++first;
  }
  return result;
}

Большая часть проверок здесь делается во время компиляции согласно требованиям, которые шаблон предъявляет к своим параметрам. Условие while также проверяет корректность взаимного расположения итераторов. Никаких дополнительных if-ов не нужно. Написано всё очень умно.

IGPIGP · 23.07.2019, 10:50

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

В стандарте таких требований нет. У стандарта иные задачи.

Первая фраза, совпадает с тем, что я говорю. И этот ответ я предполагал услышать. Вторая часть, не соответствует истине. Но я не хочу обсуждать задачи стандарта. Это слишком общая тема. Мы тута в 3-х соснах упрели.

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

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

Лучше кому и для чего? jugu, я привёл пример из stl. Это простой и логичный пример, - vector это самая людная/модная/центральная часть. А оператор индексирования - неотъемлемая часть vector. Тут нет ни чего случайного. Кроме мнений ряда профессионалов about.

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

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

То есть вас убедит, если некий академик Иванов И.И. или профессор Smith S.S. давал такие рекомендации?

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

@jugu · 23.07.2019, 11:05

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

Лучше кому и для чего?

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

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

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

jugu, я привёл пример из stl.

Пример из STL вроде я привел (см. пару постов выше). И пояснил, почему он хорош. И показал, что в нем на самом деле "скрыта" куча проверок аргументов.

IGPIGP · 23.07.2019, 11:14

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

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

Учение Ленина верно потому что оно СПРАВЕДЛИВО!
jugu, это уже не имеет смысла. Вы думаете выбор от [] до at(size_type) случаен?
Тема данного топика :