стиль binutils и gcc

[etybaxe]

может быть и глупый вопрос но все-же:

после ночи копания в сорсах binutils и gcc, от местного стиля несколько поехала кругом голова, ну зачем писать:

if(h)
{
	struct elf_mips_link_hash_entry *hmips;
	hmips = (struct elf_mips_link_hash_entry*)h;
	hmips->mips_non_lazy_relocs = true;
}

когда можно просто

h && ((struct elf_mips_link_hash_entry*)h)->mips_non_lazy_relocs = true;

????

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

но больше всего радуют получающиеся в результате лаконичные функции, вроде mips_elf_relocate_section по 60! страниц кода, где вложенность кондиционалов и свитчей уходит в бесконечность.... причем в среднем исходнике их набито под 500 килобайт - маленький такой сорсик

или возможно в таком стиле есть что-то хорошее? вроде как иногда поощеряется большое количество строк в исходнике, и очень осмысленные коментарии вроде:

/*********************************
*
*
*  main() function
*
*
***************************************/

main()
/* ... */

[Byte]

etybaxe писал(а) Птн, 09 Июня 2006 05:16

когда можно просто h && ((struct elf_mips_link_hash_entry*)h)->mips_non_lazy_relocs = true; ???? причем весь код в такой веселой радости, наверное если ее убрать, то все скомпилится раза вдва быстрей.

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

[etybaxe]

Byte писал(а) Птн, 09 Июня 2006 18:31

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

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

еще иногда переносят '{' на новую строку после кондиционалов; зачем это, ведь for/if/while открывают кондиционал, и скобка тут сама по себе не имеет отдельного смысла.

так-же часто используются веселые названия локальных переменных, вроде left_operand, right_operand вместо a и b.

imho стиль gnu, как и тот, что принят микрософтом, это то как делат не стоить.

[Ineu]

etybaxe писал(а) Птн, 09 Июня 2006 20:58

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

Почему? Время парсинга не обязательно определяется количеством строк кода.

Цитата:

еще иногда переносят '{' на новую строку после кондиционалов; зачем это, ведь for/if/while открывают кондиционал, и скобка тут сама по себе не имеет отдельного смысла.

Я переношу Затем, что мне так нравится. Для симметрии

Цитата:

так-же часто используются веселые названия локальных переменных, вроде left_operand, right_operand вместо a и b.

Хм... я такого не видел, но если такое есть - это бред, конечно Причем исключительно в этом контексте, в других случаях именно a и b - это зло.

Цитата:

imho стиль gnu, как и тот, что принят микрософтом, это то как делат не стоить.

Стиль унифицируется для возможности поддержки продукта большим количеством людей и совместной разработки. Для этих же целей часто не используются многие возможности Си - красивую и эффективную формулу порою очень непросто понять...

Стиль же Микрософта - это мой ночной кошмар, не надо на ночь вспоминать

[etybaxe]

EvilShadow писал(а) Птн, 09 Июня 2006 22:21

Почему? Время парсинга не обязательно определяется количеством строк кода.

это зависит скорей от компилятора, но C в он может довольно быстро разобрать, в моем примере компилятор:

1) читает все выражение до терминатора ';'

2) разбитвает на блоки

3) сразу выделяет h как переменную просто читая до &&

4) идет идет вглубь скобок определяя контент как поинтер

5) к которому прибавляется mips_non_lazy_relocs

6) + константа true

это все очень простой парсинг, с парой локапов в хэш тейбл, в Си коде тоже будет в 6 строк.

в варианте gnu, ему придется поднятся обратно до более выскокой функции парсинга кондиционалов, и на несколько вызовов суб-функции парсера выражений и локапов в хэш тейбл больше; хотя все зависит от дизайна компилятора =/

ну а оптимизатор разумеется от этого быстрее работать не станет, разве что мы все кондиционалы на goto заменим =)

EvilShadow писал(а) Птн, 09 Июня 2006 22:21

Я переношу Затем, что мне так нравится. Для симметрии

красота но не всегда облегчает понимание кодеры ядра Linux по этому даже статью написали, но это как спор между Big Endian и Little Endian - первый более красивый, второй более практичный... так что постоянно вспоминаем Свифта

EvilShadow писал(а) Птн, 09 Июня 2006 22:21

Хм... я такого не видел, но если такое есть - это бред, конечно Причем исключительно в этом контексте, в других случаях именно a и b - это зло.

для глобальных длинные имена ok, а внутри функции обычно не нужно больше 3-х переменных x, y, z. в C++ глобальных вообще не должно быть, посему все имена короткие.

EvilShadow писал(а) Птн, 09 Июня 2006 22:21

Стиль унифицируется для возможности поддержки продукта большим количеством людей и совместной разработки. Для этих же целей часто не используются многие возможности Си - красивую и эффективную формулу порою очень непросто понять... Стиль же Микрософта - это мой ночной кошмар, не надо на ночь вспоминать

в микрософт тоже унифицировали и получились переменные с красивыми названиями mpdwsNumberOfInstances (потренируйтесь в быстром написании ), что расшифровывается как "member private dword static", хотя я сам использую префикс m для данных класса, но не более, ибо даже это лишне при отсутствии глобальных переменных, и макро, а NumberOfInstances можно записать как ninst, и поставить в декларации коментарий, посему в C++ префиксы ненужны вообще.

[Byte]

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

а по поводу а, b, c... и т.д. позволю себе не согласиться, - не так уж удобно разбирать даже свои старые тексты когда в функции вместо strTmp стоит какая-нить s...

[Ineu]

etybaxe писал(а) Птн, 09 Июня 2006 23:46

EvilShadow писал(а) Птн, 09 Июня 2006 22:21 Я переношу Затем, что мне так нравится. Для симметрии красота но не всегда облегчает понимание кодеры ядра Linux по этому даже статью написали, но это как спор между Big Endian и Little Endian - первый более красивый, второй более практичный... так что постоянно вспоминаем Свифта

Зато часто доставляет эстетическое удовольствие от собственного кода

Цитата:

в микрософт тоже унифицировали и получились переменные с красивыми названиями mpdwsNumberOfInstances (потренируйтесь в быстром написании ), что расшифровывается как "member private dword static", хотя я сам использую префикс m для данных класса, но не более, ибо даже это лишне при отсутствии глобальных переменных, и макро, а NumberOfInstances можно записать как ninst, и поставить в декларации коментарий, посему в C++ префиксы ненужны вообще.

Спасибо, тренировался уже... мне не понравилось

[etybaxe]

Byte писал(а) Сбт, 10 Июня 2006 00:57

А, по моему, зря вы так, господа, на венгерскую нотацию наезжаете... идея хорошая, вот только не совсем удобно, порой, реализована... а по поводу а, b, c... и т.д. позволю себе не согласиться, - не так уж удобно разбирать даже свои старые тексты когда в функции вместо strTmp стоит какая-нить s...

обычно следуют классической нотации a, b, c / x, y, z / v, u для коротко-живущих скалярных, p и q для байтовых, s для строк, t для временных переменных, а r для конечно результата, при этом коментируем все непонятные переменные.

[Byte]

Ну и как называть, согласно этой нотации временную строковую переменную? s или t ? времена меняются... то, что было приемлемо в 70-80 не совсем подходит сейчас...

Зачем словесно комментировать все непонятные переменные, если можно заключить комментарий в названии самой переменной?

[etybaxe]

Byte писал(а) Сбт, 10 Июня 2006 11:32

Зачем словесно комментировать все непонятные переменные, если можно заключить комментарий в названии самой переменной?

по идее непонятных переменных быть вообще не должно, и проще один раз коментировать и/или принять какую-нибудь условность (вроде сказать нет глобальным переменным и макросам) чем сто раз писать mTemporayFileDecriptor вместо t а сокращения вроде ninst обще приняты и понятны. а пременную можно назвать tstr, или tmpstr.

возвращаясь к GNU, недавно компилил GCC3 и кучу старинного софта c помощью GCC4, результатом получил кучу ошибок связаных исчезновением расширения cast-as-lvalue (не считая более веселых о poisoned символах), при этом сей экстеншен испарился абсолютно безо всякого следа, как будто его и не было не говоря уже об отсутствии возможности вернуть старое поведение, и добавить автоматическую правку. то-же случилось и с CPP_PREDEFINES, которая сначала была poisoned, а ныне и вовсе исчезла.

[Ineu]

Кстати, в дистрибутивах очень редко делают глобальные замены софта. В одной системе живут вместе куча autocono'ов, например, и практически всегда есть gcc предыдущей ветки.

[AccessD]