[pnp_mechanic 2]

 Си компилятор "Cosmic" IdeaSTM8 v 5.4.1 2012 года имеет ограничения для типа INT не более 0хFFFF. 

Подскажите кто работает с "Cosmic" IdeaSTM8 2016 года, это ограничение присутствует ?

Есть ли смысл устанавливать в замен старого, оформлять  лицензию....?

Изменено 8 декабря, 2018 пользователем pnp_mechanic

[jcxz 184]

14 минут назад, pnp_mechanic сказал:

Есть ли смысл устанавливать в замен старого, оформлять  лицензию....?

Речь идёт о компиляции старого кода или написании нового? Если первое, то - а Вы уверены, что даже если вдруг размер int в какой-то версии вдруг будет увеличен до 32 бит, то Ваш код не перестанет работать?

Если второе, то - какая разница какой там int? Берите unsigned long и все дела.

PS: По первой причине, разработчики компилятора, если они в своём уме, никогда не будут вдруг изменять размер какого-то базового типа. Зачем? Чтобы у всех их пользователей в новой версии перестал работать их старый код и им всё нужно было переписывать???   Так всех пользователей недолго потерять....

[Arlleex 131]

Я лично определил для себя типы известной размерности и их пользую. Либо всякие unit32_t, либо пишу свои typedef unsigned long u32 (как пример), в соответствии с документацией на компилятор.

[pnp_mechanic 2]

Вот что я вижу в файле "\COSMIC\CXSTM8_EVAL\Hstm8\limits.h"

#ifndef __LIMITS__
#define __LIMITS__  1
#define CHAR_BIT    8
#define CHAR_MAX    255
#define CHAR_MIN    0
#define INT_MAX     32767
#define INT_MIN   (-32768)
#define LONG_MAX    2147483647
#define LONG_MIN  (-2147483648)
#define MB_LEN_MAX  1
#define SCHAR_MAX   127
#define SCHAR_MIN (-128)
#define SHRT_MAX    32767
#define SHRT_MIN  (-32768)
#define UCHAR_MAX   0xff
#define UINT_MAX    0xffff
#define ULONG_MAX   0xffffffff
#define USHRT_MAX   0xffff
#endif

Вы правы документацию на компилятор мне нужно изучить  ;-))

[juvf 10]

В 08.12.2018 в 16:07, pnp_mechanic сказал:

 имеет ограничения для типа INT

ни когда не используй базовые int, short, long, char(для байтовых переменных). Инклудь stdint.h (и stdbool.h) и использую ТОЛЬКО uint16_t, (u)int8_t, (u)int32_t. Ни когда не будешь думать, что там в новой версии компилятора, и всегда сможешь без болезненно перейти на другой компилятор, вообще сможешь безболезненно перейти на другую архитектуру. И ни когда не будешь думать char знаковый или нет?

[jcxz 184]

58 минут назад, juvf сказал:

ни когда не используй базовые int, short, long, char(для байтовых переменных). Инклудь stdint.h (и stdbool.h) и использую ТОЛЬКО uint16_t, (u)int8_t, (u)int32_t.

Очень сомнительное утверждение. Тем более так категорично. Никогда не говори "никогда".

Если скажем имеется цикл for, то какого типа переменную цикла позволите определять, при условии что количество итераций должно быть == 10?

А если аргумент функции имеет диапазон 0...100 - какого типа его следует делать?

[juvf 10]

8 часов назад, jcxz сказал:

Никогда не говори "никогда". 

ни когда не используй базовые int, short, long, char(для байтовых переменных).

[jcxz 184]

1 час назад, juvf сказал:

ни когда не используй базовые int, short, long, char(для байтовых переменных).

По делу есть что сказать? По заданным конкретным вопросам?

[juvf 10]

25 минут назад, jcxz сказал:

По делу есть что сказать? По заданным вопросам?

по делу я сказал. по твоим заданным вопросам - мне до езды твои вопросы. тебе очередной холивар нужен? если есть что по делу сказать - говори.

[jcxz 184]

2 часа назад, juvf сказал:

по делу я сказал. по твоим заданным вопросам - мне до езды твои вопросы. тебе очередной холивар нужен? если есть что по делу сказать - говори.

"Cадись - два!..."

В указанных случаях, например на ARM (и на других архитектурах) следует использовать int (или unsigned int). всякие uint8_t будут приводить к неоптимальному коду.

PS: Может перестанем хамить и лучше чему-нить поучимся?

[VladislavS 29]

12 часов назад, jcxz сказал:

Если скажем имеется цикл for, то какого типа переменную цикла позволите определять,

auto :)

[jcxz 184]

7 минут назад, VladislavS сказал:

auto :)

Есть такой тип? Никогда не использовал...  

[VladislavS 29]

В С++11 ещё появился. STM8, правда, это скорее всего, не светит.

for(auto i=0; i<=10; i++){ };

 

[jcxz 184]

38 минут назад, VladislavS сказал:

В С++11 ещё появился. STM8, правда, это скорее всего, не светит.

for(auto i=0; i<=10; i++){ };

 

Спасибо. Буду иметь в виду.

[juvf 10]

18 минут назад, jcxz сказал:

всякие uint8_t будут приводить к неоптимальному коду.

пруф или пи... чтохочутоговорю

Про то, что на АРМ-ах (хотя тут про STM8 речь, поэтому плиз и про STM8), в любом компиляторе и именно и в модальности "будут", а не "могут".