Можно ли использовать char как int ?

однако чаще попадаешь между границами выравнивания...

Я буду тебе сильно признателен, если не будешь вываливать дерьмо из своей головы в ответах на мои коменты.

ну я не в курсе. Есть разве платформы с беззнаковым char'ом? Мне только знаковый попадался. Я вообще думал всегда, что signed просто опускается за ненадобностью, однако всегда присутствует неявно. Не?

«In C++, there are three distinct character types: char signed char unsigned char » (c) На стековерфлоу это платиновый тред.

ИМХО ненужное буквокопание в стандарте.

Я буду тебе сильно признателен, если не будешь вываливать дерьмо из своей головы в ответах на мои коменты.

а я — тебе. Когда ты начнёшь свои диванные теории проверять на практике.

Из стандарта.

Ненужное буквокопание - источник ВНЕЗАПНОГО при встрече с платформой, которая стандарт поддерживает, но... не так как ты привык :) У нас есть одно тело в офисе - у него что ни инструмент, то открытия :) «Оказывается git работает не так как svn... Фу, какой плохой негодный git» (с) Аналогично с кроссплатформенностью... «Фу какой негодный gcc, он работает не так как msvc»(с) А всего лишь надо было буквы в стандарте знакомые поискать.

Незнание того можно ли использовать char как int вы называете нулевыми? Ясно.

Разумеется. Это показывает полное незнание основ языка, это выявляет полное непонимание концепции типов. В общем прочти для начала страуструпа.

1. не будешь выполнять с ними арифм. операций, т.к. он часто является знаковым типом. Нужнен unsigned char или ~uint8_t;

Можно тупо использовать unsigned char и все дела.

2. и если не будешь прямо мапить его на сырые данные, он может быть не равным 8 битам.

Ну сильно сомнительно, что ОП использует архитектуры с не 8битными байтами.

Из стандарта.

Вроде нет в стнадарте такого. Там вообще циферок вроде особо и нет. Там написанно, что char - это минимальный адресуемый целочисленный тип, который способен вместить в себе базовый набор символов. Дальше говорится, что char <= short <= int <= long

И вообще я бы крайне не советовал ОПу думать сейчас о том, что быстрее - использование char, или int.

Как правило основные проблемы с производительностью лежать 1) в хреновой алгоритмике. Если у тебя хреновый алгоритм (или его реализация), то никакие использование быстрых типов, регистровых переменых, ассемблерные вставки тебе не помогут. 2) плохом понимание языка. Если ты будешь постоянно передавать объекты и структуру по значению, то потеряешь в скорости и памяти гораздо больше, чем выиграешь от использования int. Тем более компилятор может вполне себе оптимизировать использование char.

Нет нет, пишу на Qt, и то, основной приоритет для linux, я просто всегда думал есть в c++ byte

Я не знаю делфи. Что там за тип byte? 8-битовое целое? Ну так это и есть char, в чём проблема? Только учти, что написание просто char = signed char, это целое со знаком длиной 8 бит. Если тебе нужно беззнаковое целое длиной 8 бит то это unsignd char. Насчёт скорости - это конечно зависит от многих факторов, но при прочих равных данные типа int чаще обрабатываются быстрее.

Что мешает пойти и прочитать?

5.2.4.2.1

тут ты прав. Ну будем знать...

в стандарте не нашёл.

а, ну да, есть там минимум INT_MAX

Кроме минимального размера в битах стандарт C++ гарантирует, что

1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long).

что одинаково?

Чтение/запись int8_t и int32_t при условии, что alignment соблюдён.

Скорость зависит от алгоритма работы с данными. Например с полными пикселями (например RGBA) удобнее работать через uint32_t и использовать макросы/inline функции и работать с отдельными цветами с помощью масок. На ARM'е так же, (хотя на современных лучше поизголяться с векторизацией повторяющихся операций), а нот на AVR или MSP430 - уже совсем не так. И на 16-битных DSP тоже не так (их лучше бы вообще для графики не использовать).

Да, если операция потоковая, то есть над всеми пикселями делается одинаковая операция, выгоднее использовать 64-битные регистры x86, и читать/;писать соответственно по 64 бита. Но это для amd64, 32-битные тут в пролёте.

Да, если операция потоковая, то есть над всеми пикселями делается одинаковая операция, выгоднее использовать AVX

Не благодари за ремонт.

Ну, не всегда оно есть. С другой стороны - на x86 я совсем мимокрокодил, умею только опции компилятору подставлять, так что интересно было бы подробности послушать.

и использовать 8 бит на канал, я могу все числа хранить в char ? П.С. для меня не важна память, важна скорость работы, если хранить все в int (32 or 64 bit) будет медленнее?

можешь, например «typedef uintXX_t RGB;», вместо XX подставить 8,16,32,64; Используя uint8_t можно наступить на грабли например с 12-ти битными каналами или с элементарными переполнениями при вычислениях - лучше (и быстрее) использовать тот-же тип и размерность что и для полного цвета: меньше преобразований, проще выделять и складывать.

для меня не важна память, важна скорость работы, если хранить все в int (32 or 64 bit) будет медленнее?

на самом деле вдоль :-) зависит от алгоритмов. int ровно по размеру шины, зато char`ов больше влезает на страницу памяти; С вашим текущем уровнем (без обид) даже не думайте про подобные оптимизации - пишите по возможности яснее.

PS. уважайте свой код и НИКОГДА не пишите как тут некоторые советуют «typedef .... byte» - вы работаете с цветом и называйте сущности их собственными именами.

И что? Какой вывод из твоего твитта можно (нужно) сделать.

Забыл цитату вставить, сорри.

2. и если не будешь прямо мапить его на сырые данные, он может быть не равным 8 битам.

И что? Какой вывод из твоего твитта можно (нужно) сделать.

Что char имеет размер 1 байт, а архитектур где 1 байт не равен 8 битам уже вроде не осталось.

Хранить не важно в чём, важно к чему скастуешь в данный момент для данной операции.
А ещё лучше написать пару функций для получения доступа к нужному 'элементу' изображения, например к отдельному каналу цвета или ко всему пикселю. При этом возможно с конвертацией в нужный формат.

мне надо работать с цвета изображение, и использовать 8 бит на канал

Используй один uint для одного RBGA-пикселя

Что char имеет размер 1 байт, а архитектур где 1 байт не равен 8 битам уже вроде не осталось.

это мелочь вроде микроконтроллеров, DSP и т.п.

Чтение/запись int8_t и int32_t при условии, что alignment соблюдён.

_одно_ чтение/запись и это не случай топикстартера. В остальном инты будут сливать.

Да, если операция потоковая, то есть над всеми пикселями делается одинаковая операция, выгоднее использовать 64-битные регистры x86

x86 уже какое-то время имеет фичу write combining, не обязательно делать это «руками»

пишу на Qt

qint8 quint8

А в C++ нет

Вроде нет в стнадарте такого

В стандарте C99 есть:

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

— maximum value for an object of type unsigned int

UINT_MAX                  65535 // 216 − 1