Господа, есть вопрос.
Полдня потратил на вылавливание косяка в программе.

Есть функция, которая принимает параметр типа unsigned int:

void Func(unsigned int i)

Косяк был в том, что я подставлял туда переменную типа unsigned char, умноженную на некое число. КОгда произведение unsigned char на это число не превышало 256, все было нормально, когда превышало - начинались косяки.
Т.Е., не важно какого типа переменная произведения, если один из множителей unsigned char, произведение выше 256 никак не получится.

Нашлось 2 решения.
Первое - сделать эту переменную типа unsigned int.
Второе - поставить в настройках галочку - "promote char to int".

По последнему пункту вопрос - что все-таки делает эта галка? Преобразуетт char в int по необхоидмости, или же преобразуются все char переменные?
Меня беспокоит экономия памяти, вот я и думаю - какое из приведенных решений рациональней - первое или второе?

Спасибо.

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

Послушайте, ну я же написал - "нашлось 2 решения", значит помогло, значит с этой галочкой работает.
Или же я вас неправильно понял...

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

Странно это..В случае умножения или сложения одинаковых типов следить за переполнением должен программист и опция "promote char to int" влиять вроде-бы не должна.
из хэлпа CV:
Checking the Promote char to int check box enables the ANSI promotion of char operands to int.
To prevent overflow on 8 bit addition or multiplication, casting may be required.
The compiler issues warnings in these situations.
Example:

void main(void) {
unsigned char a=30;
unsigned char b=128;
unsigned int c;


/* This will generate an incorrect result, because the multiplication
is done on 8 bits producing an 8 bit result, which overflows.
Only after the multiplication, the 8 bit result is promoted to
unsigned int */
c=a*b;


/* Here casting forces the multiplication to be done on 16 bits,
producing an 16 bit result, without overflow */
c=(unsigned int) a*b;
}

практически ваш случай,если я правильно вас понимаю.

И ещё раз скажу это: CodeVision в топку!!!! ))))

Типы не одинаковые. Насколько я понял ТС умножал char на константу, а константа - это Int

2 TC: Сделайте приведение типа к int по месту:

XVR, спасибо, но дело не в этом. ПРоблемы то не существует, есть два решения, вы просто предложили третье. Я всего лишь хотел знать - чем чревато жесткое включение приведения типов указанной галочкой.

Тем, что CV нагенерит много лишнего кода, что отрицательно скажется на размере занятого FLASH (и может быть на скорости работы). Может отрицательно сказаться и на работоспособности, если где то 'программист' (именно так - в кавычках) заложится на 8ми битную арифметику с char

тут обсуждали преобразование типов в CV

http://electronix.ru/forum/lofiversion/index.php/t46523.html

http://electronix.ru/forum/lofiversion/index.php/t64571.html


CodeVision из топки!
forever рулёз!

з.ы. с чего-то нужно начинать CV -самое то , а то можно и не дотерпеть до результата.

не поверите, размер снизился на 0,5%. Про скорость не знаю.... Субъективно ничего не изменилось, тесты проводить лень.



CodeVision хорош тем, что его просто освоить.

Но... портит стиль программирования. КОгда я занялся ARM, я это понял.

Да ладно вам, люди. Уж что что, а начинать и привыкать нужно к правильному. И тут CV может как-бы оказать медвежью услугу...

А вот с этого места поподробнее пожалуйста! Хочу перейти на ARM и уже запасся CV, а тут такой пост... И что является правильным по сравнению с CV?

CV (Codevision) - он только для AVR бывает.
Для ARM много чего есть: keil, iar, realview, gcc и куча его производных...

Я бы сказал, что CV использует компилятор с Си-подобного языка программирования ))
Нарушения стандарта там встречаются практически повсеместно. Привыкнув к такому компилятору - можно потом жестоко обламываться пересев на нормальный. И всё ничего - если бы был в этом какой-то реальный профит... А так...ну что там, ну чуть удобнее некоторые вещи написал/объявил... и что из этого? А ничего ) Всё то-же самое можно сделать на Си. Зато ты практикуешь реально универсальный и сильный Си, который пригодится всегда и везде, а не какой-то там кодэ вижн. Вот.

Мда... Лажанулся... Прошу прощения. Читал CV, а думал почему-то про Keil.

Не, Keil это хорошо. Даже очень хорошо))

Скажу, как пересевший с CV на Кейл

К CV возвращаться не хочется. В основном- из-за удобства оформления компилятора.

Опыт общения с ним и внимание к соответствию типов имеет , в общем-то положительный результат.

Офигенно не хватало спецификатора "eeprom", очень жалел поначалу. Но, написав библиотеку для внешней памяти, стало полегче.

Из "отрицательных" навыков - писать выражение в несколько строчек- немного увеличивало размер написанного (не компилируемого) кода.

Также порадовало что некоторые математические функции, (тригонометрия) передранные из CV, работают быстрее нежели армовские. Возможно, в ущерб точности.