etybaxe Опубликовано 9 июня, 2006 Жалоба Опубликовано 9 июня, 2006 может быть и глупый вопрос но все-же: после ночи копания в сорсах 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 Опубликовано 9 июня, 2006 Жалоба Опубликовано 9 июня, 2006 etybaxe писал(а) Птн, 09 Июня 2006 05:16 когда можно просто h && ((struct elf_mips_link_hash_entry*)h)->mips_non_lazy_relocs = true; ???? причем весь код в такой веселой радости, наверное если ее убрать, то все скомпилится раза вдва быстрей. а вы уверены, что при такой записи бинарный получится компактнее и производительнее? что удобнее писать не всегда удобнее компилировать... Цитата
etybaxe Опубликовано 9 июня, 2006 Автор Жалоба Опубликовано 9 июня, 2006 Byte писал(а) Птн, 09 Июня 2006 18:31 а вы уверены, что при такой записи бинарный получится компактнее и производительнее? что удобнее писать не всегда удобнее компилировать... уменьшится время парсинга и первоначального и разбора на базовые составляющие, да и читать будет проще: одна мысль - одна строка. еще иногда переносят '{' на новую строку после кондиционалов; зачем это, ведь for/if/while открывают кондиционал, и скобка тут сама по себе не имеет отдельного смысла. так-же часто используются веселые названия локальных переменных, вроде left_operand, right_operand вместо a и b. imho стиль gnu, как и тот, что принят микрософтом, это то как делат не стоить. Цитата
Ineu Опубликовано 9 июня, 2006 Жалоба Опубликовано 9 июня, 2006 etybaxe писал(а) Птн, 09 Июня 2006 20:58 уменьшится время парсинга и первоначального и разбора на базовые составляющие, да и читать будет проще: одна мысль - одна строка. Почему? Время парсинга не обязательно определяется количеством строк кода. Цитата: еще иногда переносят '{' на новую строку после кондиционалов; зачем это, ведь for/if/while открывают кондиционал, и скобка тут сама по себе не имеет отдельного смысла. Я переношу Затем, что мне так нравится. Для симметрии Цитата: так-же часто используются веселые названия локальных переменных, вроде left_operand, right_operand вместо a и b. Хм... я такого не видел, но если такое есть - это бред, конечно Причем исключительно в этом контексте, в других случаях именно a и b - это зло. Цитата: imho стиль gnu, как и тот, что принят микрософтом, это то как делат не стоить. Стиль унифицируется для возможности поддержки продукта большим количеством людей и совместной разработки. Для этих же целей часто не используются многие возможности Си - красивую и эффективную формулу порою очень непросто понять... Стиль же Микрософта - это мой ночной кошмар, не надо на ночь вспоминать Цитата
etybaxe Опубликовано 9 июня, 2006 Автор Жалоба Опубликовано 9 июня, 2006 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 Опубликовано 9 июня, 2006 Жалоба Опубликовано 9 июня, 2006 А, по моему, зря вы так, господа, на венгерскую нотацию наезжаете... идея хорошая, вот только не совсем удобно, порой, реализована... а по поводу а, b, c... и т.д. позволю себе не согласиться, - не так уж удобно разбирать даже свои старые тексты когда в функции вместо strTmp стоит какая-нить s... Цитата
Ineu Опубликовано 9 июня, 2006 Жалоба Опубликовано 9 июня, 2006 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 Опубликовано 9 июня, 2006 Автор Жалоба Опубликовано 9 июня, 2006 Byte писал(а) Сбт, 10 Июня 2006 00:57 А, по моему, зря вы так, господа, на венгерскую нотацию наезжаете... идея хорошая, вот только не совсем удобно, порой, реализована... а по поводу а, b, c... и т.д. позволю себе не согласиться, - не так уж удобно разбирать даже свои старые тексты когда в функции вместо strTmp стоит какая-нить s... обычно следуют классической нотации a, b, c / x, y, z / v, u для коротко-живущих скалярных, p и q для байтовых, s для строк, t для временных переменных, а r для конечно результата, при этом коментируем все непонятные переменные. Цитата
Byte Опубликовано 10 июня, 2006 Жалоба Опубликовано 10 июня, 2006 Ну и как называть, согласно этой нотации временную строковую переменную? s или t ? времена меняются... то, что было приемлемо в 70-80 не совсем подходит сейчас... Зачем словесно комментировать все непонятные переменные, если можно заключить комментарий в названии самой переменной? Цитата
etybaxe Опубликовано 10 июня, 2006 Автор Жалоба Опубликовано 10 июня, 2006 Byte писал(а) Сбт, 10 Июня 2006 11:32 Зачем словесно комментировать все непонятные переменные, если можно заключить комментарий в названии самой переменной? по идее непонятных переменных быть вообще не должно, и проще один раз коментировать и/или принять какую-нибудь условность (вроде сказать нет глобальным переменным и макросам) чем сто раз писать mTemporayFileDecriptor вместо t а сокращения вроде ninst обще приняты и понятны. а пременную можно назвать tstr, или tmpstr. возвращаясь к GNU, недавно компилил GCC3 и кучу старинного софта c помощью GCC4, результатом получил кучу ошибок связаных исчезновением расширения cast-as-lvalue (не считая более веселых о poisoned символах), при этом сей экстеншен испарился абсолютно безо всякого следа, как будто его и не было не говоря уже об отсутствии возможности вернуть старое поведение, и добавить автоматическую правку. то-же случилось и с CPP_PREDEFINES, которая сначала была poisoned, а ныне и вовсе исчезла. Цитата
Ineu Опубликовано 10 июня, 2006 Жалоба Опубликовано 10 июня, 2006 Кстати, в дистрибутивах очень редко делают глобальные замены софта. В одной системе живут вместе куча autocono'ов, например, и практически всегда есть gcc предыдущей ветки. Цитата
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.