Еще раз:
тернарная операция - часть основного алгоритма,
цикл - код проверки/демонстрации.
Т.е. эти две строчки, хоть и стоят рядом, относятся к разным частям программы.
То есть работа тернарного оператора никак не зависит от значения переменной цикла - мы ее задаем снаружи алгоритма. И этот тернарный оператор должен работать при любых значениях входного параметра (в данном случае - переменной цикла).
Ну же писал - измените границы цикла до любого другого числа, скажем, до 10.
void setup() {
Serial.begin(115200);
Serial.println('\n');
for(int i = 0; i < 6; i++) {
// ==== начало алгоритма, который должен работать при любых i ===
int j = i<5 ? i : 5;
Serial.print("ArrFunc in: ");
Serial.println(j);
int k = fn[j](j);
Serial.print("ArrFunc out: ");
Serial.println(k);
// ==== конец алгоритма ===
}
for(int i = 0; i < 6; i++) {
int j = i<5 ? i : 5;
Serial.print("SwitchFunc in: ");
Serial.println(j);
SwitchFunc(j);
Serial.print("SwitchFunc out: ");
Serial.println(j);
}
}
А не проще просто сделать три счётчика на милис с тремя разными интервалами - 5, 10 и 15 секунд соответственно зачем столько сложностей - массивы, циклы и прочая куча кода.
Если что я спрашиваю что бы разобраться в вопросе - действительно нужно делать все эти циклы и массивы или это уже в силу опыта или профессионализма идёт просто не нужное усложнение кода и можно обойтись тремя простыми конструкциями счетчиков с разными интервалами (собственно как и в первом сообщении ТС).
Видимо вы так же не внимательно прочитали моё сообщение как я первое в теме. Я спрашивал, а не критиковал. Ну и по итогу я понял что не так и что у ТС не получалось и дошёл к ответу сам, что без всех этих сложностей кода не обойтись.
Как выяснилось позднее, код из первого сообщения не решает и не может решить задачу, поставленную ТС. Так что “упрощение” в данном случае означает потерю работоспособности.
Любую задачу можно решить разными способами (имеется в виду - решить правильно, - а не так, как в первом сообщении).
Счетчики сами по себе не такая простая конструкция, как может показаться на первый взгляд. В частности, у них изначально отсутствует механизм синхронизации между собой. А дополнение этим механизмом существенно усложнит код.
Из “2.” совсем не следует, что существует какой-то единственный оптимальный способ. Обычно при разных условиях оптимальными могут оказаться различные варианты. Профессионалы в качестве критериев оптимальности выделяют надежность кода, его масштабируемость и простоту поддержки. Ни один из этих критериев не совпадает с минимизацией объема кода. Поэтому “нужное” усложнение кода или “не нужное” решает сам программист.
зачем столько сложностей - массивы, циклы и прочая куча кода.
. Ну и видимо почти могу сам себе ответить на заданный мною вопрос.
