ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
7 июля
207290 Топик полностью
fk0, легенда (23.08.2010 14:25, просмотров: 166) ответил testerplus на Про возможные ошибки - да, тут спасут сообщения. Да и разбрасывание определений по .c и .h на мой взгляд тоже неудобно. А ентеров и пробелов - где-то перегиб, но в целом правильное предписание. К тому же это их внутренний циркуляр.
Про переопределение типов -- чушь и бред! "Мой велосипед лучше, чем бородатые дяденьки из комитетов ISO напридумывали". Ага... Все необходимые типы стандартом предусмотрены, более того, базовые типы неспроста жёстко не ограничены -- это повышает эффективность кодогенератора (если говнокод не писать). Для 16-битных CPU, разумеется, 16-битный int эффективен. И надо думать, что если может быть больше INT_MAX, то в переносимом коде надо явно писать long. Или не надо. И дяденьки свой кругозор не ограничивали одним единственным в мире компилятором на одном единственном в мире MCU. Любимый некоторыми самодельный byte может работать в разы медленее int на RISC, где и команд-то для работы с байтами нет, шина 16/32-битная и невыравненное обращение карается сразу. И char по стандарту может иметь любую знаковость, как удобнее. это просто знать нужно. если кому-то нужен знак -- есть signed char, unsigned char, int_fast8_t, uint8_t и другие типы. А налажать с самодельными typedef можно запросто и спотыкаться потом о ту же знаковость и неизвестно что ещё. Особенно при переносе кода на другую архитектуру. Самодельный тип -- его ж, между прочим, ни в printf не впихнёшь (а если там, не дай бог, не printf, а другая функция, не проверяемая компилятором на соответствие типа формату?), ни констант MIN/MAX нет адекватных (а неадекватные, взяты с другого CPU -- глюкодром в вычислениях). А про самодельные intptr_t или sig_atomic_t даже представить страшно. Разве что, при смене платформы всё внимательно 10 раз перепроверять и переделывать аккуратно. Только зачем, спрашивается, этот самодельный велосипед нужен, если в компиляторе оно давно всё сделано, отлажено и баги отловлены и исправлены? Единственное оправдание -- качество компиляторов заявленных "ANSI-C" часто ниже некуда, C89 они часто не соответствуют толком, C99 очень редко вообще (а без C99 более половины полезных вещей -- нет). За исключением GCC и его производных (C30, KEIL и т.п.), чтоб бы там не говорили о поделках финских студентов...
[ZX]