Вы записали очень длинные функции? Если так, почему?
Некоторые вещи думать о при выборе между этими механизмами:
- Вы просто хотите stdout, или Вам нужен stderr также? или даже выделенный?
- , Насколько большой Ваш вывод? Вы хотите держать весь результат в памяти?
- Вы хотите считать часть своего вывода, в то время как подпроцесс все еще работает?
- Вы должны закончиться коды?
- Вам нужен рубиновый объект, который представляет процесс и позволяет Вам уничтожить его по требованию?
Вам, возможно, понадобится что-либо от простых обратных галочек (''), система (), и IO.popen к полноценному Kernel.fork / Kernel.exec с IO.pipe и IO.select.
можно также хотеть бросить тайм-ауты в соединение, если подпроцесс занимает слишком много времени выполняться.
, К сожалению, это очень зависит .
7 ответов
Самые длинные функции все, что я когда-либо писал, имеют одну общую черту - очень большой оператор switch. Бывают случаи, когда вам нужно включить длинный список элементов, и это только усложнит понимание, если вы попытаетесь реорганизовать некоторые параметры в отдельную функцию. Наличие больших операторов switch делает цикломатическую сложность зашкаливающей, но часто она лучше, чем альтернативные реализации.
Бывают случаи, когда вам нужно включить длинный список элементов, и это только усложнит понимание, если вы попытаетесь реорганизовать некоторые параметры в отдельную функцию. Наличие больших операторов switch делает цикломатическую сложность зашкаливающей, но часто она лучше, чем альтернативные реализации. Бывают случаи, когда вам нужно включить длинный список элементов, и это только усложнит понимание, если вы попытаетесь реорганизовать некоторые параметры в отдельную функцию. Наличие больших операторов switch делает цикломатическую сложность зашкаливающей, но часто она лучше, чем альтернативные реализации.Предыдущее задание: очень длинный оператор case, IIRC 1000+ строк. Это было задолго до объектов. Каждый вариант состоял всего из нескольких строк. Разделение сделало бы его менее ясным. На самом деле существовала пара таких подпрограмм, выполняющих разные действия с одним и тем же базовым набором типов данных.
Извините, у меня больше нет кода, и я все равно не могу публиковать его.
Самая длинная функция, которую я не считал ужасной, будет ключевым методом настраиваемой виртуальной машины ЦП. Как и в случае с @epotter, здесь использовался большой оператор переключения. Фактически, я бы сказал, что многие методы, которые, как я считаю, не могут быть полностью разбиты или улучшены в удобочитаемости, включают в себя операторы переключения.
К сожалению, вы не часто найдете этот тип подпрограмм зарегистрированным или опубликованным где-нибудь, если он автоматически сгенерирован на этапе сборки с использованием какого-то генератора кода.
Так что ищите проекты, в которых есть C создан на другом языке.
Помимо производительности, я думаю, что размер стека вызовов в пространстве ядра составляет 8 КБ (пожалуйста, проверьте размер). Кроме того, насколько мне известно, код в ядре довольно специфичен. Если какой-то код вряд ли будет повторно использован в будущем, зачем делать его функцией, учитывая накладные расходы на вызов функции.
Я могу представить, что когда важна скорость (например, при удержании какой-то блокировки в ядре), вы не захотите разбивать функцию из-за накладных расходов из-за выполнения функционального вызова . При компиляции параметры должны быть помещены в стек, а данные должны быть извлечены перед возвратом. Поэтому из соображений эффективности у вас может быть большая функция.