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

[inventor]

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

[Tahoe]

Пользуйте, если их уродство глаз не режет, только не надо фантазий о их чудодейственной силе.

Я ж сказал, что глаз режет.

А вот за собственным языком лучше следить. На эти "фантазии" день-два убил, пока выяснил. А все претензии и ворчания рекомендую адресовать не мне, а тем, кто занимался стандартной билиотекой. Уверен, они с удовольствием выслушают и примут меры по мотивам этой чрезвычайно конструктивной критики.

А то, что муть " PRIu64 " есть ни что иное, как макрос-обертка llu это никакой мыслью в Вас в голове не отозвалось?

Код

#define __STRINGIFY(a) #a
#define __PRI64(x) __STRINGIFY(l##x)
#define PRIu64        __PRI64(u)

Так что "проверяй" не проверяй.

Да-да, конечно-конечно. Осталось только самая малость, убедиться, что в _любом_ компилере это выглядит точно так же.

[zltigo]

Да-да, конечно-конечно. Осталось только самая малость, убедиться, что в _любом_ компилере это выглядит точно так же.

Ну выглядит по разному, например, так:

CODE

#define PRIu64  "llu"

А знаете почему ВСЕГДА в результате такое для <64bit платформ, а для 64bit просто без ll? Потому, что все эти PRIu64 пишутся в разрыве кавычек текстовой строки. Это из-за того, что это макроподстановка текстовой строки в текстовую строку. И НИКАК иначе. Если-бы эти чудотворящие корявобуквоцифросочетания были-бы не макросами, то все выгдядело:

printf( "ll = %PRIu64\n", ll );

а не:
printf( "ll = %" PRIu64 "\n", ll );

Вот такой прикол
Вообще это просто кое как сделанная "стандартная" заплатка для обеспечения портирования между 32 и 64bit платформами более ни для чего ненужная.

[Tahoe]

Это из-за того, что это макроподстановка текстовой строки в текстовую строку. И НИКАК иначе.

Ага. "Я гарантирую это" (с).

А "не приходило в голову"(с) более очевидное: это для того, что бы _иметь_возможность_ реализовать в виде макроподстановки? Есть гарантия, что всегда и везде это реализовано именно в виде макроподстановки? Гарантия, разумеется, не от zltigo, а нечто более официальное.

И небольшой намек, как может быть реализовано.

[scifi]

Есть гарантия, что всегда и везде это реализовано именно в виде макроподстановки? Гарантия, разумеется, не от zltigo, а нечто более официальное.

О господи. Вот:

Each of the following object-like macros expands to a character string literal
containing a conversion specifier, possibly modified by a length modifier, suitable for use
within the format argument of a formatted input/output function when converting the
corresponding integer type.

Это C99. Официальнее некуда. Советую заглядывать туда иногда прежде чем гнуть пальцы. А то как-то комично получается.

[zltigo]

И небольшой намек, как может быть реализовано.

Господи да каким боком-то здесь intrinsic функции. Уж не сочтите за труд без намеков разверуться, так сказать, во всей своей красе и показать все глубины своих представлений о языке.

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

Вы можете продолжать спорить, но когда после перехода на 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 компилятора - достаточно любого голого препроцессора. Единственное нормальное решение это ОБЯЗАТЕЛЬНОЕ введение однозначных префиксов.

[inventor]

Он и поддерживает. Должно быть так:

Код

long long    ll = 100500;
printf( "ll = %" PRIu64 "\n\r", ll );

Остальное по аналогии можно найти самостоятельно. См. например тут или тут.

И лучше отойти от всех этих неопределенных short, long и т.п. В Це99 существуют более внятные типы, вроде uint32_t, uint64_t, int64_t...

Я СВОИ дефиниции именно так и реализовал

#define u64 int64_t

итд

[zltigo]

Я СВОИ дефиниции именно так и реализовал

#define u64 int64_t

Вообще-то это ужасно, когда так пишут.
1) int64_t это никак не unsigned
2) О typedef Автору слышать не приходилось

CODE

typedef uint64_t u64

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

Такое заплаточное "решение" лежит на поверхности и для его реализации совершенно не требуется C99 компилятора - достаточно любого голого препроцессора.

Для его реализации необходим препроцессор. Но достаточно C99 компилятора, в котором это реализовано совершенно однозначно и одинаково у всех компиляторописателей для всех архитектур. Творить свой велосипед нет никакой необходимости - он будет ничем не лучше. Можно просто посмотреть на календарь и выкинуть уже компилятор, цепляющийся за стандарт 26-летней давности. Уже под все архитектуры существуют компиляторы, поддерживающие 16-летний стандарт.

[inventor]

Вообще-то это ужасно, когда так пишут.
1) int64_t это никак не unsigned
2) О typedef Автору слышать не приходилось

Код

typedef uint64_t u64

ну да ошибся
конечно uint64_t

[megajohn]

хм, как то странно отработал printf c long long


P.S. исправил - заработало. Стек задачи для теста забыл выровнять на 8. Топик-стартер, учел это ?

[zltigo]

Для его реализации необходим препроцессор.

Все с точностью до наоборот. Необходимы изменения в компиляторе.

Но достаточно C99 компилятора, в котором это реализовано совершенно однозначно и одинаково у всех компиляторописателей для всех архитектур.

Компилятор к этой заплатке ни сном ни духом - просто дефайны в хидере заменяющие на классические "u" и "ull". В ранее приведенном примере как раз дефайны из GCC.
Так-что латать можно абсолютно все.

Творить свой велосипед нет никакой необходимости - он будет ничем не лучше.

Про "свой" речь не идет, поскольку это должен быть компилятор, но лучше будет тем, что это будет поддерживаться железно, не потребует разборок и коррекций в хидере с тем, каков
сейчас размер int, ну и в конце-концов будет смотреться естественно, без дополнительный "". Минус тоже есть - разборка строки становится больше. Но я все-же за новые форматы типа %I64 и компиляторы их поддерживающие.

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

К заплаткам компилятор не имеет отношения. А вот то, что за 26 лет так и не ввели в ОБЯЗАТЕЛЬНЫЙ стандарт однозначных форматов, а ограничились заплатками через препроцессор, это печально.

Уже под все архитектуры существуют компиляторы, поддерживающие 16-летний стандарт.

Неужели . Увы, нет . Даже формальное наличие, например, GCC компилятора котрый кто-то сваял, например, под M8C не позволит мне на него перейти с какого-нибудь Image Craft. Ибо отличия в диалекте весьма велики, а в каких-нибудь Intrinsic, да и поросто ASM, просто фатальны. Такая-же история даже с казалось-бы массовыми PIC16 и Hi-Tech компиляторами. Так-что с C99 все не так благостно.