Переменные long long Опции

[inventor]

Как правильно использовать в IAR ?
Процессор Texas Instruments CC3200
Хочу присвоить переменной время в наносекундах или микросекундах
пишется какая то лажа - printf ничего не выводит, хотя пытаюсь и %lld и %Ld
компилятор C99 и вроде должен поддерживать все эти вещи

[Сергей Борщ]

Вы можете продолжать спорить, но когда после перехода на 64-битную ОС у меня компилятор начал ругаться на printf("%lu", uint64_t_var), который прекрасно собирался на 32-битной системе (поскольку uint64_t из unsigned long превратился в unsigned int), для меня вопрос использования форматных макросов PRIxxx решился сам собой. Еще раньше я накалывался на аналогичное с uint32_t при переносе кода AVR<->PC, но поскольку на AVR я printf использую крайне редко, это не сильно напрягало. Я никого не убеждаю, каждый сам ест свой кактус.

[zltigo]

Вы можете продолжать спорить, но когда после перехода на 64-битную ОС у меня компилятор начал ругаться на printf("%lu", uint64_t_var), который прекрасно собирался на 32-битной системе (поскольку uint64_t из unsigned long превратился в unsigned int), для меня вопрос использования форматных макросов PRIxxx решился сам собой.

Вопрос ведь не в использовании заплатки, где надо, а в ее использовании где НЕ НАДО и о том, что работа этого чудотворящего макроса НИЧЕМ не отличается от llu в контексте 32bit ARM. Так что твоя реплика не по делу. Ну и по хорошему, а не через заплатку, такой вопрос решается через новые префиксы типа I64, но это пока отдано на откуп компилятору, хотя многие уже поддерживают.

[Сергей Борщ]

а в ее использовании где НЕ НАДО

Можно озвучить критерии надо/не надо? Мне очень трудно заранее предугадать - будет код переноситься (хотя бы для тестирования) на другую платформу или нет. Поэтому сразу использую описанный в стандарте путь - PRIxx. Он работает всегда в отличие от. Так же как сразу использую (u)intXX_t, из "голых" типов у меня в программах остался только char для хранения символов. Это тоже описанный в стандарте путь и работает он всегда.

P.S. Я то сначала думал, что придирка к сообщению №10 пошла из-за объявления переменной long long и дальнейшего использования в строке формата PRIu64, т.е. если объявили long long, то и в строке формата надо использовать llu, а если хотим использовать PRIu64, то и переменную надо было объявлять как uint64_t ("Вы или трусы наденьте, или крестик снимите"), а потом смотрю - нет, тут оказывается сам факт использования PRIu64 объявлен ересью. С этим я согласиться не могу.

[zltigo]

Можно озвучить критерии надо/не надо? Мне очень трудно заранее предугадать

Ну вот если "трудно", тогда и используй. Мне пока совершенно не тудно предугадывать, что даже пренося для тестирования на 64bit платформу мне незачем компилировать, как 64bit приложение. Зато ломать глаза об эти заплатки, действительно трудно. Ну b на пути портирования printf() и других проблем, типа полноты реализаций , хватает.

Так же как сразу использую (u)intXX_t, из "голых" типов у меня в программах остался только char для хранения символов.

С этим проще, чем с printf() - я тоже "голых" типов почти не использую (char и int, int полезен тем, что нативный для платформы и может использован де-факто для всего, чему достаточно от 8 до 16bit ), но и (u)intXX_t в явном виде тоже по причине того, что есть typedef
Ведь проблемы с портированием 8->16->32->64 появилист ЗАДОЛГО до C99. Так что решал я эти проблемы уже 80-x годах и посему у меня с тех пор "свои" типы:
uchar, bint, ushort... Пишется-читается мне легче, а из "проблем" портирования редактирование одного *.h файла, тем более, что все равно часто при смене платформы меняется не только разрядность, и вот просто так ничего совсем не делая не получится. Да и новыми типами все не так радужно. При том-же портировании 8->16 большая пробоема в изобилии 8bit переменных, которых на других платформах 8bit корявы и приводят к тормознутости. Так у меня появилась 'bint', которая для все не восьмибитовых является int. C появлением C99 компиляторов я у себя в хидере заменил ее на "least" - поверил, работает, но оказалось НЕ всегда. Компилятор на свое усмотрение то 8, то 32 бита таки переменные делал. Так что сначала заменил ее на "fast", а потом и обратно на тупой int.

тут оказывается сам факт использования PRIu64 объявлен ересью. С этим я согласиться не могу.

Ересью НЕ объявлен. Просто назван тем, чем он является на самом деле - ЗАПЛАТКОЙ. Примитивной заплаткой для того, что-бы хоть создать какую-то видимость решения ЯВНОЙ ПРОБЛЕМЫ заложенной отцом-основателем языка. Как и ЛЮБУЮ ЗАПЛАТКУ ее надо использовать только в вынужденых случаях, а не где попало, типа на всякий случай.
Такое заплаточное "решение" лежит на поверхности и для его реализации совершенно не требуется C99 компилятора - достаточно любого голого препроцессора. Единственное нормальное решение это ОБЯЗАТЕЛЬНОЕ введение однозначных префиксов.

[Kabdim]

char и int, int полезен тем, что нативный для платформы и может использован де-факто для всего, чему достаточно от 8 до 16bit

Для этого есть не менее стандартные типы аля int_fast8_t и int_fast16_t - и сразу из текста программы ясно что было достаточно (двух)байтовой переменной в отличии от char'а / int'а на том же месте.

Сообщение отредактировал Kabdim - Sep 8 2015, 12:45