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

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

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

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

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

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

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

@jugu · 22.07.2019, 19:26

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

@rams · 22.07.2019, 19:33 **[ТС]**

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

Отвечает тоже вызывающая сторона

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

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

немного противоречат друг другу не находите

@jugu · 22.07.2019, 19:40

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

немного противоречат друг другу не находите

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

@rams · 22.07.2019, 19:54 **[ТС]**

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

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

Это отражено в стандарте или вы сами придумали. Мысль конечно не плохая.

IGPIGP · 22.07.2019, 20:47

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

немного противоречат друг другу не находите

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

@jugu · 22.07.2019, 20:53

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

Это отражено в стандарте или вы сами придумали. Мысль конечно не плохая.

К сожалению, придумал не я, а те, кто стоял у истоков программирования на языках высокого уровня.

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

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

Конечно. Проверять дважды не эффективно. Но решать, - программисту.

Всё зависит от того, что это за функция, где, как и кем она будет использоваться. Нас учили в свое время, что хорошая функция должна адекватно реагировать на любые комбинации аргументов, правильные они или нет. К сожалению, на 100% это обеспечить можно далеко не всегда.

Evg · 22.07.2019, 21:00

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

Т.е. если ты вызываешь printf("%d", some_int) и подставляешь туда нечто не int

У тебя вопрос стоИт в контексте эллипса (параметров с тремя точками) или чего? А то если аргумент функции объявлен как int, а туда передают, например, float, то по правилам языка построится преобразование типов. А это уже совсем из другой оперы

@hoggy · 22.07.2019, 21:08

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

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

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

есть такое понятие "инвариант".
это - способность функции сохранять работоспособность
независимо от корректности вызывающей стороны.

хороший код - инвариантен.

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

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

C
1
2
// функция в принципе не способна валидировать аргументы
int process(const int* array, const size_t count);

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

@Eanmos · 22.07.2019, 21:15

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

Конечно. Проверять дважды не эффективно. Но решать, - программисту.

Добавлю, что обычно для проверки корректности использования внутреннего API используют assertions, например:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/*
===============
Creates a viewport with the specified width and height.
 
@param v Is a valid pointer to a Viewport structure.
@param w The viewport's width in range [0, VIEWPORT_MAX_WIDTH].
@param h The viewport's height in range [0, VIEWPORT_MAX_HEIGHT].
===============
*/
void Viewport_Create(Viewport *v, unsigned int w, unsigned int h)
{
    assert(v != NULL);
    assert(w <= VIEWPORT_MAX_WIDTH);
    assert(h <= VIEWPORT_MAX_HEIGHT);
 
    SDL_CreateWindowAndRenderer(w, h, 0, &v->window, &v->renderer);
 
    v->width = w;
    v->height = h;
}

Так что говорить о неэффективности не приходится.

IGPIGP · 22.07.2019, 21:49

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

Всё зависит от того, что это за функция, где, как и кем она будет использоваться.

Существуют прямые и точные указания?

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

Так что говорить о неэффективности не приходится.

assert в релиз не компилируется и является отладочным кодом. В этом смысле он не является кодом функции в заданной теме. Хотя к теме и относится, конечно.

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

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

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

@hoggy · 22.07.2019, 22:27

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

Поэтому - холивар по определению.

по какому такому определению?

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

Это просто быстрее.

"быстрее" - это вопрос дизайна и принципов обработок ошибок.

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

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

У вызывающей стороны может быть гораздо больше эффективных способов обеспечить "инвариант"

не может, по определению понятия "инвариант".

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

"инвариант".
это - способность функции сохранять работоспособность
независимо от корректности вызывающей стороны.

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

Она порождает значения аргументов и знает о них больше чем функция.

есть ещё понятие "инкапсуляция".

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

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

когда верхние и нижние этажи пишутся с оглядкой друг на друга - это говнокод.

@rams · 22.07.2019, 22:32 **[ТС]**

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

IGPIGP · 22.07.2019, 22:57

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

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

Вызывающая сторона - внешний мир. И она должна знать о функции. Деталей реализации не нужно знать. Но если нет возможности понять, что для функции съедобно, а что нет, то это и есть

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

говнокод

Другой вопрос, это то, что с ростом сложности, отслеживание логики для вызова становится бесполезной затеей. Для этого и OOP. Там идеома "чёрного ящика", о которой вы настойчиво говорите, реализуется по-человечески.
И всё же, решать разработчику, что ему выбрать. Делать код который будет падать/бросать исключения при отладке и тестировании, до тех пор пока не будут устранены причины. Либо делать код который будет тихо поедать всё что ему скармливают. Сроки, деньги и доступные ресурсы не последний аргумент. Проще всего идти по второму пути. Я не спорю. Но это не самый быстрый вариант.

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

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

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

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

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

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

Я за вариант корректность аргументов дело того кто использует, а не того кто пишет почти на 100%.

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

@jugu · 22.07.2019, 23:06

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

Существуют прямые и точные указания?

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

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

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

Я за вариант корректность аргументов дело того кто использует, а не того кто пишет почти на 100%.

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

IGPIGP · 22.07.2019, 23:08

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

Одно из таких требований - универсальность, т.е. работа с любыми данными, не только корректными.

Где это требование изложено?
jugu, я не спорю о том, что как рекомендация, это имеет право на жизнь. Я говорил о том, что не существует способа написать такое требование задав точные границы. То есть, оно не может быть частью разумного стандарта.

Croessmah · 22.07.2019, 23:10

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

или указание стандарта на который можно сослаться

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

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

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

Но о процентах я бы не говорил

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

@Eanmos · 22.07.2019, 23:17

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

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

Опять же, такая проверка имеет смысл в форме

C
1
2
3
4
5
int getRand(int min, int max)
{
    assert(min < max);
    ...
}

Чтобы исключить ошибки при использовании API разработчиками. Такой способ просто не даст использовать функцию неправильно. Хотя можно заранее обговорить действия, выполняемые при передаче в функцию неверных аргументов (специальное возвращаемое значение, errno и т. д.).

@rikimaru2013 · 22.07.2019, 23:18

Не по теме:

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

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

А где тут хамство?

Новые блоги и статьи Все статьи Все блоги /
Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. На мобильном - сканируйте QR-код. Вращайте камеру одним пальцем,. . .	SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .
Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка библиотек: SDL3, Box2D, FreeType, SDL3_ttf, SDL3_mixer и SDL3_image из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .

@rams 24 / 24 / 5 Регистрация: 04.04.2012 Сообщений: 107

	Кто отвечает за корректность аргументов функции? 22.07.2019, 19:23. Показов 6153. Ответов 72 Метки ascii c (Все метки) Вопрос к знатокам стандарта или просто ведующим. В языке c за корректность аргументов обычно отвечает вызывающая сторона. Т.е. если ты вызываешь printf("%d", some_int) и подставляешь туда нечто не int, то это твои проблемы потом удивляться, недоумевать или возмущаться на некорректный вывод или уход в даун. А с++ какая практика? 1

@jugu 611 / 416 / 151 Регистрация: 11.01.2019 Сообщений: 1,746
	22.07.2019, 19:26
	Отвечает тоже вызывающая сторона, но автор функции должен так разработать ее интерфейс, чтобы некорректные аргументы было сложно подставить. Ну и, конечно, первыми операторами должны идти всевозможные проверки корректности аргументов с заменой неверных дефолтными значениями либо выбросом исключений. 1

@rams 24 / 24 / 5 Регистрация: 04.04.2012 Сообщений: 107
	22.07.2019, 22:32 [ТС]
	Я за вариант корректность аргументов дело того кто использует, а не того кто пишет почти на 100%. Просто есть максималисты ну типа см. выше. И доводы что обычно проверок и так хватает и проверять еще и аргументы значит еще более все усложнять не работают. Вот я подумал может есть какой то гуру или указание стандарта на который можно сослаться. 0