Было бы лучше использовать fseek + троичный или IF?
fseek( pChunk, (iCurChar < 31) ? ftell(pChunk)+((31-iCurChar)+1) : ftell(pChunk), 0 );
Если условие не выполнено, нам не следует никуда перемещаться в файле. Что будет проще с ресурсами: иметь этот тернарный код или создать, если это не делает по сути бессмысленную «fseek( ftell() )»?
Я думаю, что разница на современных машинах практически незначительна, но я действительно не уверен, что мне следует делать. Управление ресурсами здесь очень важно, поэтому я бы хотел использовать как можно меньше, даже если это незначительно.
Я посмотрел, что о них говорят люди, и некоторые мнения разошлись. Я думаю, что этот случай довольно уникален, потому что с тройной операцией также используется дополнительная операция (fseek to ftell). Я не знаю, насколько большой будет разница, и у меня нет никакого опыта в сравнительном анализе.
Зачем ты вообще fseekпоешь, когда тебе это не нужно? if (iCurChar < 31) { fseek(pChunk, 32 - iCurChar, SEEK_CUR); } выглядит как то, что вам нужно, и сводит два безусловных системных вызова к одному условному вызову. Меньшее количество системных вызовов — это большое дело, эта бессмысленная попытка создать код без ветвей (который все еще разветвляется), похоже, не служит никакой цели, и любая «экономия», которую она может дать, будет более чем устранена даже одним дополнительным системным вызовом. .
Почему вы используете 0 в качестве третьего параметра? fseek указано, чтобы принимать значение SEEK_CUR, SEEK_END или SEEK_SET. Похоже, вы думаете, что 0 может быть SEEK_SET, но это не понятно читателям и не переносимо.
Как указывает @ShadowRanger, троичная версия по-прежнему является ветвью/условием (потенциально создавая ветвь сборки или условный переход). Чтобы уточнить, кажется, у вас сложилось впечатление, что тернарные операторы имеют лучшую производительность, чем эквивалентный оператор if. Это очень маловероятно в современном оптимизирующем компиляторе.
Вы сравнивали сборку двух версий? Вы профилировали их? Была ли существенная разница, чтобы оправдать даже заботу об этом?
Мне никогда не было легко разобрать троичную операцию, и я редко ее использую. Это просто сокращенная версия if ... else.
@WeatherVane Пожалуй, единственное применение, которое я когда-либо нашел для любого тернарного оператора, - это в контексте таких вещей, как аргументы для *printf(), где NULL следует избегать. Например prinf( "some arg: %s", arg ? arg : "<null>" ); В остальном они просто злодеи, создающие из кода нечитаемый беспорядок.
Даже быстрый поиск в Интернете приводит к выводу, что тройные числа имеют очень ограниченное применение. Этот случай точно не один. Разве у вас нет правил кодирования, которым нужно следовать?
Ответы 1
Хотя заявления о стиле кода довольно часто являются субъективными мнениями, я вполне уверен, что форма
if (iCurChar < 31)
fseek(pChunk, (31-iCurChar) + 1, SEEK_CUR);
было бы, несомненно, предпочтительнее во всех отношениях. Тернарный оператор имеет свои применения, но это не одно из них.
В общем, тернарный оператор полезен, когда вам нужно сделать что-то условно, но в контексте, где по какой-либо причине оператор if невозможен. Но здесь, при принятии решения, звонить fseek или нет, обычное утверждение if определенно является вариантом — это предпочтительный вариант!
Ничего не получится, вызывая fseek безоговорочно, а затем, через «ложную» ветвь вашего тернарного оператора, умудряясь, чтобы этот вызов fseek иногда ничего не делал.
fseek уже является быстрым вызовом, поскольку, по сути, все, что он делает, — это корректирует указатели или смещения в читаемом файле. Так что в попытках ускорить звонок на fseek практически нет процентов. Непонятно, какое незначительное преимущество, по вашему мнению, можно получить, используя тернарный оператор (и некоторые ненужные вызовы ftell) таким образом, но я могу вам сказать, что преимущество не является «незначительным»; оно отсутствует (или отрицательно). Даже в среде с наиболее ограниченными ресурсами чистая и очевидная форма подойдет.
Пишите понятный и краткий код, а микрооптимизацию оставьте компилятору. Не сразу понятно, что делает ваш код.