@rams

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

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

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

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

1

@jugu

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

1

@rams

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

0

@jugu

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

0

@rams

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

0

IGPIGP

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

0

@jugu

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

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

0

Evg

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

0

@hoggy

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

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

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

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

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

2

@Eanmos

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

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

0

IGPIGP

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

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

0

@hoggy

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

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

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

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

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

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

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

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

0

@rams

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

0

IGPIGP

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

Добавлено через 4 минуты
hoggy, хамите сударь.

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

0

@jugu

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

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

0

IGPIGP

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

0

Croessmah

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

1

@rams

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

1

@Eanmos

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

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

0

@rikimaru2013

0