testerplus (23.08.2010 12:41, просмотров: 133) ответил Vladimir Ljaschko на Добавляю переменные в globals.c и .h. Ну тупо так все выглядит делать два раза. А кто-нить использует препроцессор для этого дела?-
- На счёт возможных ошибок -- надумано. warning или error дают все компиляторы. Зато нарушается принцип "не плодить сущностей сверх необходимого", что ведёт к бардаку, говнокоду и ошибкам. И программисту не видно в *.c переменной -- размазывается код по fk0(1250 знак., 23.08.2010 13:29)
- Про возможные ошибки - да, тут спасут сообщения. Да и разбрасывание определений по .c и .h на мой взгляд тоже неудобно. А ентеров и пробелов - где-то перегиб, но в целом правильное предписание. К тому же это их внутренний циркуляр. testerplus(1045 знак., 23.08.2010 14:02)
- Странно-странно. Насколько я помню, по стандарту char должен иметь достаточно места для того, чтобы вместить базовый набор симвлов, а размер всего остального идёт через кратность char-у. Теоретически вроде как можно сделать short unsigned int ReAl(229 знак., 23.08.2010 17:44 - 17:47)
- Он и занимает один бит памяти (т.е. 8 штук утолкаются кимпилятором в один байт). Там даже массивы можно объявлять, только они не работают. - testerplus(23.08.2010 18:05)
- Ну и как это соответствует стандарту? - ReAl(23.08.2010 18:20)
- Никак. Я же и говорю, что это исключение. Просто когда приходится работать с разными компиляторами, надо полагаться в первую очередь на конкретную реализацию, во вторую - на стандарты. Поэтому я и считаю переопределение стандартных типов необходимостью. - testerplus(23.08.2010 18:27)
- Ну лучше бы вели нестандартное имя для такого, как bit в Keil/MCS51, чем настолько отклоняться от стандарта. Расширение стандарта терпимее, чем нарушение. - ReAl(24.08.2010 00:13)
- а когда в контроллере 41 байт ОЗУ? и да, на ассемблере не быстрее. - Alex B.(24.08.2010 01:56)
- "41 байт ОЗУ контроллера" и "нефиг ради однобитового типа данных курочить стандартный тип, лучше расширением ввести новый, как bit у Keil" - вещи ортогональные. Мои исходники для AT89C55 под Keil/51, изначально написанные с ReAl(343 знак., 24.08.2010 11:09)
- Тогда и язык Си не нужен. Да и попытка натянуть Си на PIC тоже выглядит весьма сомнительно... - SciFi(24.08.2010 10:26)
- Не вставайте в позу. Никаких преимуществ в асм vs HTPICC для мелких контроллеров не вижу. - Alex B.(24.08.2010 11:58)
- а когда в контроллере 41 байт ОЗУ? и да, на ассемблере не быстрее. - Alex B.(24.08.2010 01:56)
- Ну лучше бы вели нестандартное имя для такого, как bit в Keil/MCS51, чем настолько отклоняться от стандарта. Расширение стандарта терпимее, чем нарушение. - ReAl(24.08.2010 00:13)
- Никак. Я же и говорю, что это исключение. Просто когда приходится работать с разными компиляторами, надо полагаться в первую очередь на конкретную реализацию, во вторую - на стандарты. Поэтому я и считаю переопределение стандартных типов необходимостью. - testerplus(23.08.2010 18:27)
- Ну и как это соответствует стандарту? - ReAl(23.08.2010 18:20)
- Нет, в стандарте C99 иначе: - SciFi(23.08.2010 17:52, ссылка)
- А, ну да, ограничения снизу есть, причём даже в С89. Я имелл виду, что 1-битовый short int нарушает это: ReAl(1843 знак., 23.08.2010 18:37)
- Он и занимает один бит памяти (т.е. 8 штук утолкаются кимпилятором в один байт). Там даже массивы можно объявлять, только они не работают. - testerplus(23.08.2010 18:05)
- Если кто-то сталкивается с проблемами с размерностью при смене CPU -- говнокод. - fk0(23.08.2010 14:26)
- Про переопределение типов -- чушь и бред! "Мой велосипед лучше, чем бородатые дяденьки из комитетов ISO напридумывали". Ага... Все необходимые типы стандартом предусмотрены, более того, базовые типы неспроста жёстко не ограничены -- это повышает fk0(1767 знак., 23.08.2010 14:25)
- Библиотека типов stdint.h есть далеко не везде (к примеру тот же PICC18, а еще Visual C++, Borland C++ и упомянутый Вами C30). Их по-любому придется доопределять. Ляброш просто предложил свою систему именования (повторюсь: этот документ - их внутренний testerplus(946 знак., 23.08.2010 15:22)
- Жёсткие типы в реальности нужны редко. Это скорей признак говнокода. И "вызывают коллизии" как раз в говнокоде -- аккуратный код работает везде без трудностей переноса. "C" имеет все средства для этого. - fk0(23.08.2010 16:52)
- Лучше сделать самодельный stdint.h по образу и подобию, чем говнокодить самодельные велосипеды с квадратными колёсами. - fk0(23.08.2010 16:50)
- Библиотека типов stdint.h есть далеко не везде (к примеру тот же PICC18, а еще Visual C++, Borland C++ и упомянутый Вами C30). Их по-любому придется доопределять. Ляброш просто предложил свою систему именования (повторюсь: этот документ - их внутренний testerplus(946 знак., 23.08.2010 15:22)
- Создатели компиляторов должны руководствоваться ISO-9989, а не собственной логикой. CSS не является ANSI/ISO компилятором. Это компилятор "языка CSS". И с C там только синтаксис общий... - fk0(23.08.2010 14:10)
- ISO 9899 (не 9989) не регламентирует размерность целых типов. - testerplus(23.08.2010 14:19)
- Неправда. Он даёт пределы (limits.h), которые должны выполняться точно или с превышением. Кроме того, обязаны существовать типы (u)int_least8_t, (u)int_least16_t, (u)int_least32_t, (u)int_least64_t. См. стандарт. - SciFi(23.08.2010 15:38)
- Стандарт не дает пределы, а предписывает разработчиков компилятора снабжать программистов файлом "limits.h" с описанием пределов. К примеру для C32 в этом файле INT_MAX определен как 0x7FFFFFFF. testerplus(255 знак., 23.08.2010 16:16)
- Не вводите людей в заблуждение. "Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign." - это про те самые пределы. Так что стандарт гарантирует, что пределы для SciFi(36 знак., 23.08.2010 16:52)
- Да, Вы правы. testerplus(117 знак., 23.08.2010 16:58)
- Не вводите людей в заблуждение. "Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign." - это про те самые пределы. Так что стандарт гарантирует, что пределы для SciFi(36 знак., 23.08.2010 16:52)
- Стандарт не дает пределы, а предписывает разработчиков компилятора снабжать программистов файлом "limits.h" с описанием пределов. К примеру для C32 в этом файле INT_MAX определен как 0x7FFFFFFF. testerplus(255 знак., 23.08.2010 16:16)
- А ибо нефиг. Вон библиотечные функции тоже все на "нерегламентированных типах". Использовать в промежутке самодельные типы -- нарываться на неприятности. - fk0(23.08.2010 14:32)
- Неправда. Он даёт пределы (limits.h), которые должны выполняться точно или с превышением. Кроме того, обязаны существовать типы (u)int_least8_t, (u)int_least16_t, (u)int_least32_t, (u)int_least64_t. См. стандарт. - SciFi(23.08.2010 15:38)
- CCS PICC (не CSS) -> - testerplus(23.08.2010 14:13, ссылка)
- Вот именно этот ужас я и имел ввиду. - fk0(23.08.2010 14:33)
- ISO 9899 (не 9989) не регламентирует размерность целых типов. - testerplus(23.08.2010 14:19)
- Рекурсия и нужна. Вместе с рекурсией будут сообщения об ошибках. А иначе -- тишина. fk0(78 знак., 23.08.2010 14:08)
- Странно-странно. Насколько я помню, по стандарту char должен иметь достаточно места для того, чтобы вместить базовый набор симвлов, а размер всего остального идёт через кратность char-у. Теоретически вроде как можно сделать short unsigned int ReAl(229 знак., 23.08.2010 17:44 - 17:47)
- Препроцессор, при всех его опасностях, существенно систематизирует проект. Использую, много, говнокод такой симпатишный получается:)например Vladimir Ljaschko(776 знак., 23.08.2010 13:39)
- Про возможные ошибки - да, тут спасут сообщения. Да и разбрасывание определений по .c и .h на мой взгляд тоже неудобно. А ентеров и пробелов - где-то перегиб, но в целом правильное предписание. К тому же это их внутренний циркуляр. testerplus(1045 знак., 23.08.2010 14:02)
- На счёт возможных ошибок -- надумано. warning или error дают все компиляторы. Зато нарушается принцип "не плодить сущностей сверх необходимого", что ведёт к бардаку, говнокоду и ошибкам. И программисту не видно в *.c переменной -- размазывается код по fk0(1250 знак., 23.08.2010 13:29)