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

rtfm

Тебе работодатель поставил условием С++? Просто интересно откуда берутся новые плюсеры.

gcc -std=c++11

#include<cstdint>

uint8_t byte=123;

Кто мешает? '0' = 48 и далее. Есть short ещё, если тебе уж даже инт много будет .

Некоторые сами, лулзов ради.

Та я давно перешел на с++. Но учить ЯП не для меня)(хотя книжку по нему я все же прочитал). Все равно на реальных задач все лучше учится.

Та я давно перешел на с++. Но учить ЯП не для меня)(хотя книжку по нему я все же прочитал).

Ё..., наверно http://i24.fastpic.ru/big/2011/0718/dd/e4a06b12b29ffd8ba80fcd03d4d7dadd.jpg

Тебе нужен uint8_t.

Не просто можно, все так и делают.

Как Вам пришла в голову идея программировать на языке, которого Вы совершенно не знаете, при полностью нулевых знаниях о, собственно, программировании?

можно

использовать 8 бит на канал

uint8_t

в С++ нет byte

typedef unsigned char byte;

год программирование на дельфи, пол года на с++. Нулевые знания) + математика...

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

uint8_t

можно, если

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

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

год программирование на дельфи

делфи не считается

пол года на с++

этого слишком мало для плюсов

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

Я разрешаю.

А почему бы просто не использовать 32-битный int на пиксель?

тогда придётся создавать тред про битовые маски и сдвиги :)

Просто интересно откуда берутся новые плюсеры.

Пока rust не наберет обороты(хотя и его мало, видимо будут еще развиваться подобные языки) - они по прежнему будут появляться.

да, можешь. нет, с int медленнее не будет. А может даже быстрее.

Использовать иногда можно. Погугли про EOF в файловых операциях.

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

Вопрос не совсем корректен. Диапазон целочисленного типа char от -128 до 127, unsigned char от 0 до 255. Как в 32-разрядной ОС так и в 64-разрядной занимает 8 бит. А как ты его будешь использовать - твои проблемы. Типу int он равен быть не может. Но если я не ошибаюсь данные типа int обрабатываются быстрее чем char, хоть и занимают больше памяти.

А что, кто-то тебе запрещает? Только учти, что твой char на деле все равно может занять 4, а то и все 8 байт!

Но если я не ошибаюсь данные типа int обрабатываются быстрее чем char, хоть и занимают больше памяти.

Обычно вроде инт оптимизирован под текущую архитектуру, поэтому в общем случае может быть быстрее. Но, например, для 8-битных AVRок, под которые мне приходилось писать, инт занимал 2 байта и был не самым оптимальным по скорости.

Нужно. Хотя есть библиотеки с восьмибитными интами и прочим. Память экономить надо.

А на чём ещё ты предлагаешь писать нативщину без всяких рантаймов? На Расте? Или может, на Хачкеле?

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

Если нужно не просто хранить, а ещё что-то считать по картинке, то может быть значительно медленнее. Чем меньше памяти используешь, тем лучше попадаешь в кеши.

Просто интересно откуда берутся новые плюсеры.

Будто выбор офигенно большой. Для десктопов нормальных вариантов всего два - питон и плюсы. Ну и жаба с шарпом в ынтерпрайзе.

Ну разумеется нужно учитывать модель данных ОС, просто увидев упоминание делфи я предположил что речь скорее всего идёт о Windows - ILP32 или LLP64. А там int = 32 бита, но операции с ним выполняются быстрее. Впрочем и в Linux также. Но это конечно не значит что так везде, например на 16-разрядных DOS если память не изменяет int != 32 бита.

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

int меньше смысла нету. Если я ничего не путаю, то быстродействие будет если твоя переменная = машинному слову, делать меньше смысла нету.

Pascal же. Как будто это что-то плохое.

Обычно вроде инт оптимизирован под текущую архитектуру, поэтому в общем случае может быть быстрее

Да.

инт занимал 2 байта

Инт не может быть меньше 16 бит.

Это прекрасно :)

Капс. Не Ъ.

Кто сейчас станет разбираться в чужом паскалокоде? Разве что поделки под себя на нём писать.

Если нужно не просто хранить, а ещё что-то считать по картинке, то может быть значительно медленнее. Чем меньше памяти используешь, тем лучше попадаешь в кеши.

Всё зависит от размера кешлайна и того, как работает кэш. На x86 будет по скорости одинаково, скорость будет зависеть от дальнейшей работы с данными. Unaligned access, правда, всегда медленней.

Просто интересно откуда берутся новые плюсеры.

есть множество старого кода, который друг другу перепродают инвесторы, работать он толком не может, а денег за него отваливают кучу. Это создаёт нездоровый спрос на плюсовиков.

П.С. для меня не важна память, важна скорость работы

не надо заниматься преждевременной оптизмизацией.

Всё зависит от размера кешлайна и того, как работает кэш

от этого зависит на сколько будет медленнее. Конкретно - чтение относительно большого куска данных.

На x86 будет по скорости одинаково,

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

откуда берутся новые плюсеры

Пока rust не наберет обороты

видимо будут еще развиваться подобные языки

они по прежнему будут появляться

они - это новые языки :) А плюсеры будут появляться независимо от баззвордов и прочих «похорон трупа страуса». У нас по офисам щас шарят в поисках плюсеров и вакансии выставляют - которые есть, все заняты и надолго :) Причем бывает интересно: между UI на дотнете с его WCF-ным «междуэндом» с сервисами и базой есть прослойка серваков на плюсах и сам транспорт с протоколом весь плюсовой (boost::asio во все поля, а линукс тут при том, что база почему-то на линуксе :) Где логика...)

Это бородатая байка.

Я был немного удивлен что в С++ нет byte ( которые есть в дельфи)

typedef unsigned char byte;

я могу все числа хранить в char ?

да, но будут проблемы, т.к. char он знаковый, от -128 до +127. Используй byte (см. выше), и не забывай к константам приписывать u

byte x=255u;

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

с точностью до наоборот. Хранить всё лучше всего в int. Это самый быстрый тип В ОБЩЕМ СЛУЧАЕ (но в частности uint64_t таки быстрее на x86_64, но только на нём. Ещё быстрее SEE самой верхней версии). Но лучше не заморачивайся, а юзай готовые либы, там это уже учли.

Аутсорс, может слышал? :) Есть конторы, которые даже лицензии у дебаркадера покупают (не сказать чтоб дешевые, а конторы - хе-хе, госконторы), чтобы дать аутсорсерам возможность переписать кот родом из 90-х - весь этот SQL, обмазанный формачками (в котором прямо в onClick() дергаются скрипты базы) по-человечески.

gcc -std=c++11

это, кстати не обязательно. AFAIK оно в C99 было уже.

Чем меньше памяти используешь, тем лучше попадаешь в кеши.

однако чаще попадаешь между границами выравнивания, от чего профит от кешей уменьшается, и может даже стать отрицательным. Не забывай, что L1 очень маленький и выровненный. Ну и если ты обмазался байтами, то процессор будет вынужден эти байты двигать, т.к. читать побайтно процессор давно уже не умеет, а читает как минимум по 128 бит, не меньше.

В итоге, обмазывание байтами обычно НЕ даёт выигрыша, а даёт проигрыш.

(важно: я сказал ОБЫЧНО! Это не значит «всегда»)

например на 16-разрядных DOS если память не изменяет int != 32 бита.

да, там в int 16 бит было, а в long 32.

но будут проблемы, т.к. char он знаковый

немного искусственные проблемы - они обычно именно от непонимания, что у типа есть диапазон и знаковость - посмотрел в limits.h и сразу озарение :) (А так вообще не факт же - знаковость чара она же от реализации зависит, завязываться на то, что он signed для сферического в вакууме коня нельзя, можно для конкретной платформы/реализации рантайма, для которой это известно заведомо.) Как говорится,

"In C++, there are three distinct character types:
    char
    signed char
    unsigned char
" (c)

Инт не может быть меньше 16 бит.

откуда дровишки?