Могут ли комментарии/идентификаторы влиять на производительность/работоспособность кода?

Сегодня я был представлен с wiered фактом (или нет)Могут ли комментарии/идентификаторы влиять на производительность/работоспособность кода?

было сказано:
«В это запрещено писать длинные описательные имена идентификаторов, а также запрещено писать комментарии для Linux драйверов, написанных в ANSI C»

Когда я спросил «WTF? Почему?» мне сказали, что это вызвало проблемы с исполнением и ошибки такого ...
не так много деталей там.

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

так ... Может ли это вызвать проблемы?

источник

2013-08-13 Tomer W

Ну, ANSI C является стандартом, а стандартом является то, что каждый must следует (я имею в виду проектировщиков и программистов компилятора, если они решают его поддержать).

Стандарт ANSI C утверждает, что экспортированные идентификаторы (да, экспортированные идентификаторы хранятся как символы в таблице символов, а не только адреса) не должны быть длиннее 6 символов, а неэкспортированные идентификаторы в порядке, чтобы быть не длиннее, чем 31 символ.

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

источник

2013-08-13 08:31:53

, если у меня есть идентификатор LOOOONNG, это будет ошибка времени компиляции, проблема с производительностью или ошибка, не так ли? –

@TomerW, да, например. Microsoft Visual Studio 2012 не позволяет идентификаторы длиннее 1023 символов (ошибка C1064), хотя это зависит от целевой платформы. Обратите внимание на память: более длинный идентификатор, очевидно, займет больше памяти для хранения в таблице символов.Встроенные системы (где Linux широко распространены) очень чувствительны к ресурсам, поэтому такие ограничения стиля кодирования довольно умны, даже если вы не получите ошибку компиляции на аппаратной платформе x86. –

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

Абсолютно нет. Какой бы идентификатор вы не использовали в своем коде, они будут переведены на символы компилятором.

Кроме того, все комментарии будут игнорироваться предварительным процессором компиляции.

Единственный эффект комментариев - помочь вам быстрее понять код.

источник

2013-08-13 08:31:13 gtv

Этот вопрос прямо спрашивает об ANSI C, который ограничивал поддерживаемую длину внешних идентификаторов. –

Нет, первый шаг в компиляции - предварительная обработка исходного кода для удаления комментариев и выполнение других трюков, таких как расширение макросов.

Идентификаторы часто переводятся в указатели (в записи таблицы символов).

источник

2013-08-13 08:31:56

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

@EricPostpischil, вы правы, отредактированы –

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

источник

2013-08-13 08:54:33 Devolus

Могут ли комментарии/идентификаторы влиять на производительность/работоспособность кода?

ответ

Смежные вопросы