когда блокировать вызовы функций?

#c

#c

Вопрос:

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

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

A:

 Data *someData = new Data;

while(running)
{
    ProcessData(someData);
};

void ProcessData(Data *data)
{
    if(data)
        data->member = 5;
}
  

B:

 Data *someData = new Data;

while(running)
{
    if(someData)
        ProcessData(someData);
};

void ProcessData(Data *data)
{
    data->member = 5;
}
  

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

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

итак, я спрашиваю, чего ожидать среднему разработчику в этой ситуации

Комментарии:

1. Вы спрашиваете, следует ли ProcessData() предполагать, что ‘data’ действителен до его вызова, или ProcessData() должен молча игнорировать, если он недействителен?

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

Ответ №1:

Для этого конкретного случая наиболее распространенным методом, вероятно, является

 void ProcessData(Dataamp; data) {
  data.member = 5;
}
  

Или

 void Data::Process() {
    member = 5;
}
  

Ни один из них не может быть вызван без действительного Data объекта для действия, поэтому нет необходимости в постороннем тестировании. Кроме того, документация — ваш друг: если функция может быть вызвана только после инициализации основного цикла событий, то убедитесь, что в документах функции указано «Вызывать эту функцию только после инициализации вашего основного цикла событий».

Более того, это зависит от вашей конкретной ситуации.

Ответ №2:

Вы имеете в виду, когда выполнять проверку ввода? Ну, за пределами вашего цикла > = O (n), если вы можете, проверка за O (1) время и n потенциально очень велика.

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

Комментарии:

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

Ответ №3:

Проверка вызовов методов для допустимых параметров требует затрат на производительность, но также есть «затраты» при возникновении ошибок. Например, функции ядра не могут допустить внутреннего сбоя — это может привести к сбою всей системы.

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

Ответ №4:

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