Vladimir Ljaschko (23.08.2010 12:20, просмотров: 24711)-
- можно так abivan(223 знак., 23.08.2010 12:53)
- Вместо DEF_EXTERN для каждого модуля нужно своё уникальное имя. Будешь copy&paste делать, забудешь поменять, глюки будешь искать неделю. Оно надо? - fk0(23.08.2010 13:31)
- это не защита от повторного переопределения. abivan(88 знак., 23.08.2010 15:34)
- Тут не об этом. Если несколько модулй экспортируют объявленные в них глобальные переменные, то тогда несколько таких h-файлов и для каждого необходим свой SOME_MODULE_DEF_EXTERN. Конечно, если всё в общей свалке в одном файле, то это не нужно. - ReAl(23.08.2010 17:17)
- Я про то, что заменяя extern на макрос MYEXTERN -- нужно думать, чтоб макрос MYEXTERN имел уникальное имя. Иначе при включении вложенного *.h -- понятно... - fk0(23.08.2010 16:48)
- +1. Интерфейс каждого модуля - в его .h файле. Каждая функция, видимая извне, имеет префикс в имени, совпадающий с именем модуля. - Леонид Иванович(23.08.2010 14:34)
- это не защита от повторного переопределения. abivan(88 знак., 23.08.2010 15:34)
- Вместо DEF_EXTERN для каждого модуля нужно своё уникальное имя. Будешь copy&paste делать, забудешь поменять, глюки будешь искать неделю. Оно надо? - fk0(23.08.2010 13:31)
- Нет, ибо говнокод. globals.c -- тоже. Каждому модулю -- свои глобальные переменные. - fk0(23.08.2010 12:44)
- Угу, это понятно. Но если я не понимаю, где объявлена переменная, я ищу в globals. Грязный хак против маразма. Так же как имя - не могу дважды вспомнить имя переменной - меняю имя. Настоящие программисты конечно в этом не нуждаются. - Vladimir Ljaschko(23.08.2010 12:53)
- На паскале программировал? Там есть понятие "модуля". У модуля есть интерфейс. Так вот в C точно также, если придерживаться некоторых правил: все функции/переменные видимые наружу -- суть есть интерфейс какого-то модуля. Описываются в *.h файле, fk0(363 знак., 23.08.2010 13:35)
- Да понимаю я, понимаю! Значит, не хватает силы воли структурировать модули в проектах, перетекающих из одного в другой. Там, где аппаратура, нет проблем. - Vladimir Ljaschko(23.08.2010 14:11)
- Всё общее собрать в один модуль misc_trash.c И со временем его уменьшать в размерах. - fk0(23.08.2010 14:34)
- Да понимаю я, понимаю! Значит, не хватает силы воли структурировать модули в проектах, перетекающих из одного в другой. Там, где аппаратура, нет проблем. - Vladimir Ljaschko(23.08.2010 14:11)
- +1 про говнокод. Если есть глобальная переменная, должен быть и модуль, к которому она относится. Лучше даже сделать "методы" set() и get(). Ну а про маразм: используйте Source Insight. Я на него не нарадуюсь: с ним в исходниках заблудиться невозможно. - SciFi(23.08.2010 13:12)
- +1. Обхожусь без глобальных переменных, интерфейс каждого модуля через "методы". - Леонид Иванович(23.08.2010 13:16)
- а как быть с сервисами ОС? Приемник и передатчик в разных модулях а сервис один. - abivan(23.08.2010 19:01)
- Не понял проблемы... - Леонид Иванович(23.08.2010 22:29)
- Скорость при этом не страдает? Или методы через #define get_xxx() (xxx) - AlexBi(23.08.2010 16:29)
- В любом случае, чем красивее текст программы, тем больше страдает скорость и растет объем. Леонид Иванович(371 знак., 23.08.2010 19:04)
- Раньше define, в связи с С99 static inline ReAl(227 знак., 23.08.2010 17:13)
- А... gcc... паделка студентов! - fk0(23.08.2010 19:38)
- а как быть с сервисами ОС? Приемник и передатчик в разных модулях а сервис один. - abivan(23.08.2010 19:01)
- +1. Обхожусь без глобальных переменных, интерфейс каждого модуля через "методы". - Леонид Иванович(23.08.2010 13:16)
- На паскале программировал? Там есть понятие "модуля". У модуля есть интерфейс. Так вот в C точно также, если придерживаться некоторых правил: все функции/переменные видимые наружу -- суть есть интерфейс какого-то модуля. Описываются в *.h файле, fk0(363 знак., 23.08.2010 13:35)
- Угу, это понятно. Но если я не понимаю, где объявлена переменная, я ищу в globals. Грязный хак против маразма. Так же как имя - не могу дважды вспомнить имя переменной - меняю имя. Настоящие программисты конечно в этом не нуждаются. - Vladimir Ljaschko(23.08.2010 12:53)
- В соглашении об оформлении от micrium есть п. 1.04.03 на этот счет -> - testerplus(23.08.2010 12:41, ссылка)
- На счёт возможных ошибок -- надумано. 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)
- можно так abivan(223 знак., 23.08.2010 12:53)