Вопросы по С/С++ (СИ)

[Мастер Ломастер]

боже ж мой, ну сколько можно... все бы вам готовенькое...

ну вот, например, поищите книгу Алена Голуба "Веревка достаточной длины, чтобы выстрелить себе в ногу"

но кроме этой есть и другие - ищите по ключевым словам "качественный код", "искусство написания программ" и т.п. - то есть ищите то, к чему хотите стремиться (если хотите, конечно)

[igor-x]

Добрый день.

подскажите пож. как поделить переменную unsigned int на байты для передачи по RS232?
и как собрать эти 2 байта в unsigned int после приема?
--
спасибо

[BerZerK-ku]

Вариантов куча, например так:

Код: Выделить всё

int var;
char byte1, byte2;
byte1 = var >> 8;
byte2 = var; 
Обратно:
var = (byte1 << 8) + byte2;

[BCluster]

перечисление для чисел от -12 до 130 хотя и можно при помощи enum-а, но, согласитесь, очень трудоемко .

А в чем собственно трудоемкость будет заключаться? Есть более простые методы? )
А в чем отличие енумов для Си(99) и Си++?

[Мастер Ломастер]

C++ я знаю очень плохо, но вроде как там есть возможность задавать типы-перечислители в таком виде типа -12...130, что в Си не возможно... хотя я могу быть и не прав.

ну а трудоемкость - это набить сотню-другую констант вручную

[BerZerK-ku]

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

[Мастер Ломастер]

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

тем хуже для С++ в паскале, который все гуру клянут на чем свет стоит, такое перечисление давным-давно существует, как тип данных.

[BCluster]

Мы вроде говорим о чем-то разном
Для перечисления в любом случае надо задавать имена. Или Паскаль умеет читать мысли и сам придумывает имена константам?)

[IfoR]

Дык как бы перечисления с Паскале (а точнее множества, эти ваши -12..130) и Си++ реализованы для разных целей. В паскале это массив бит, каждый из которых описывает включённость в это множество какого либо объекта. В Си++ это, если можно так сказать, средство инкапсуляции: типу перечисления можно задать ряд предопределённых, обычно осмысленных, значений, но при компиляции это всё всё равно преобразуется к целому типу, которому присваиваются целые значения, соответствующие автоматически по порядку выбранным для осмысленнозаданных.

А множеств в Си++ вроде нету... Хотя, что стоит написать библиотеку для работы с ними? Всё равно, с последних версиях C++ даже тип int - класс со своим конструктором.

[Мастер Ломастер]

Мы вроде говорим о чем-то разном

я говорю о ТИПЕ данных, а вы о чем? в частности, я в Си использую перечисления в том числе и так:

Код: Выделить всё

typedef enum{
   VALUE1 = 0,
   VALUE2 = 22,
   VALUE3
} enum_type;

enum_type my_var;

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

сами по себе перечисления в виде набора констант никому не нужны - с этим успешно справляются дефайны.

[BCluster]

я говорю о ТИПЕ данных, а вы о чем? в частности, я в Си использую перечисления в том числе и так:

Я говорю о перечислениях как о перечислениях

Как типы данных мне они неинтересны как раз сейчас. Может когда-то и пригодятся, но вряд ли Я против создания кучи типов данных, если это не структуры. Спорить тут толку нет, в книжках "о чистоте кода" я встречал и тот и другой подход, поэтому вот...
В паскале эта фигня называется "множества" если мне не изменяет память ) Но сейчас обсуждать чем паскаль хуже си и чем лучше думаю не стоит )

сами по себе перечисления в виде набора констант никому не нужны - с этим успешно справляются дефайны.

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

[Мастер Ломастер]

скажите, чем таким положительным отличается

Код: Выделить всё

#define CONST1 1
#define CONST2 2
#define CONST3 3

от

Код: Выделить всё

enum{
   CONST1 = 1,
   CONST2 = 2,
   CONST3 = 3
}

?
как второй вариант облегчает вам жизнь? где тут структуризация, систематизация и т.п. вещи, которые чем-то помогают? разве что у вас IDE с автосворачиванием блоков {} - но извините, это совершенно не то обычные дефайны, размещенные по логически разделенным заголовочным файлам ничуть не хуже систематизированы

а вот чем хорош мой подход. допустим, я объявил тип

Код: Выделить всё

typedef enum{
   KEY_1 = 1,
   KEY_2 = 2,
   KEY_3 = 3
} KEYCODES;

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

Код: Выделить всё

KEYCODES get_key(void);

а затем где-то в недрах

Код: Выделить всё

switch(get_key()){
   case KEY_1:
      // что-то там
      break;
   case KEY_2:
      // другое что-то там
      break;
}

и вот тут - СМОТРИТЕ!!! - происходит WARNING компилятора, звучащий в "переводе" так: "эй, программист! ты в switch-е не все возможные варианты значений функции перебрал!!!" скажите, без использования ТИПА-ПЕРЕЧИСЛЕНИЯ можно получить такое напоминание? согласитесь, что если вы пишите программу, где в перечислении имеется хотя бы десяток вариантов - совсем не лишним будет получить такой варнинг в случае, если что-то забыли, не так ли? аналогичные варнинги я буду получать и с указателями на этот тип, и с параметрами функций и т.п. - все это страхует от ошибок.

самые трудноуловимые ошибки (после работы с НЕТИПИЗОВАННЫМИ указателями) в Си связаны именно с тем фактом, что по стандарту этот язык прощает любые вольности с типами переменных! а мой подход хоть на капельку уменьшает эту неприятность

жалко лишь, что в упомянутой функции ничто не запретит вернуть, например, 12, и никакой варнинг при этом не всплывет но это Си...

[phenomen]

Попробуй так:

Код: Выделить всё

switch(get_key()){
   case KEY_1:
      // что-то там
      break;
   case KEY_2:
      // другое что-то там
      break;
//.............................................
//скоко надо другого чего-то там и напоследок самое вкусное:
   default:
     //unexpected key
      break;
}

Пропал ворнинг?

[BerZerK-ku]

скажите, чем таким положительным отличается
Код:
#define CONST1 1
#define CONST2 2
#define CONST3 3
от
Код:
enum{
   CONST1 = 1,
   CONST2 = 2,
   CONST3 = 3
}
?

Вообще enum лучше записывать по возможности так:

Код: Выделить всё

enum{
   CONST1 = 1,
   CONST2,
   CONST3
   ...
   CONSTN
}

В этом случае преимущество сразу же проявляется. Например, вы добавили CONST2_1 между 2 и 3. В дефайнах вам придется перебивать все последующие значения ручками.

[Мастер Ломастер]

Пропал ворнинг?

если вы считаете, что программу надо писать так, чтобы не было ворнингов - вы правы, но только при условии, что ворнингов нет потому, что нет проблем, а не потому, что вы прикостылили заплатку если у меня switch должен был обрабатывать 20 вариантов, а я реаклизовал только 19 - скажите, ваш вариант с default чем-то поможет? в данной ситуации наличие ворнинга - БЛАГО, а вы от него отказались заглушкой по умолчанию.

скажите, чем таким положительным отличается
Код:
#define CONST1 1
#define CONST2 2
#define CONST3 3
от
Код:
enum{
   CONST1 = 1,
   CONST2 = 2,
   CONST3 = 3
}
?

Вообще enum лучше записывать по возможности так:

Код: Выделить всё

enum{
   CONST1 = 1,
   CONST2,
   CONST3
   ...
   CONSTN
}

В этом случае преимущество сразу же проявляется. Например, вы добавили CONST2_1 между 2 и 3. В дефайнах вам придется перебивать все последующие значения ручками.

во-первых, такая запись - довольно редкий частный случай для последовательных констант, а, например, для упомянутого мною случая с кодами кнопок последовательность кодов вовсе не обязательна и скорее всего нерациональна.
во-вторых, в чем же преимущество? для последовательных констант совершенно безразлично, куда добавлять новые: МЕЖДУ предыдущими или В КОНЦЕ. очевидно, что продефайнить новую константу В КОНЦЕ ничуть не сложнее, чем в пустом enum.
в третьих, повторяю для упертых: смысл в ТИПЕ данных, а не enum-е, т.к. в С99 есть зачатки контроля типов, но никак не перечислений.

[BerZerK-ku]

Если честно, ничего не понял из вашего сообщения. У enum есть не мало достоинств по сравнению с дефайнами, а недостатков вроде бы и нет.
Пример из реальной программы :

Код: Выделить всё

enum eMENUparamDef
{
   PARAM_DEF_TYPE_DEF = 0,      
   PARAM_DEF_TYPE_LINE,
   PARAM_DEF_TIME_NO_MAN,
   PARAM_DEF_LINE_DELAY,
   PARAM_DEF_PULSE_OVERLAP,
   PARAM_DEF_PULSE_OVERLAP_1,
   PARAM_DEF_PULSE_OVERLAP_2,
   PARAM_DEF_RZ_DECREASE,
   PARAM_DEF_CF_DECREASE,      
   PARAM_DEF_PRD_FREQ,
   PARAM_DEF_PRM_FREQ,
   PARAM_DEF_END            
};

1. Согласно данному порядку есть массив параметров. Возникла ситуация, надо добавить пару параметров DELAY_1, DELAY_2 (а это обычное дело). Добавлять их в конец перечисления/массива параметров не есть красиво и наглядно. Соответственно в enum втыкаются пара имен и в массив в том месте добавляются нужные параметры. И не надо ничего переименовывать в enum. По-моему удобно.
2. Присваивая значение элементу перечисления / дефайну можно ошибиться и написать уже имеющееся значение, и никаких предупреждений вы не получите. Если есть возможность застраховаться, то почему бы не сделать этого?
3. Ну и подсказка не последнее в этом деле, даже в убогом редакторе IAR можно отобразить элементы перечисления. Что удобнее чем куча дефайнов.

[Мастер Ломастер]

Если честно, ничего не понял из вашего сообщения.

ничего, это бывает. прочтите больше одного раза, должно помочь

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

все прочее - это попытка натянуть штаны на голову. красиво и наглядно? так я не против - чем typedef enum в данном контектсе хуже? редактор IAR-а что-то там умеет? да какой редактор не умеет?! я, например, группирую имена дефайнов по префиксам, например, команды - CMD_, события - EV_ и т.д., и редактор Eclipse после ввода CMD_ и нажатия Ctrl-Space отлично показывает мне ВСЕ дефайны, начинающиеся с этой последовательности. удачный редактор - не аргумент за достоинства конструкции языка Си. вы что, не понимаете, что я говорю совсем о другом?! я говорю о том, как enum реально помогает избегать ошибок в программах! а вы мне про удобство добавления пунктов... я вам про теплое - вы про мягкое. одно другому не помеха и не конкурент.

[BerZerK-ku]

Был вопрос "чем положительным отличается запись и т.д." , я привел положительные стороны enum по сравнению с define. С пользой проверки даже и не думал спорить

редактор IAR-а что-то там умеет? да какой редактор не умеет?!

к сожалению его редактор не далеко ушел от блокнота, и это не было сказано во славу IAR

[Мастер Ломастер]

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

[BerZerK-ku]

Кто цеплялся?! Не выдавайте желаемое за действительное. Был вопрос, был ответ, чего не так-то Тем более, что "как второй вариант облегчает вам жизнь? где тут структуризация, систематизация и т.п. вещи, которые чем-то помогают?" ну никак не похоже на риторические вопросы.
Есть не мало ситуаций когда от проверки enum толка нет, а вот другие , пусть и не значительные, достоинства себя проявляют. Почему бы не упомянуть о них?