Господа, так что там насчет sizeof(char) == 1 решили? Уже не всегда? Или все-таки всегда? А то что-то вечером цитаты из стандарта плохо воспринимаются...

bsa, решили, что всегда, но не всегда эта единица означает один байт... точнее она означает байт в интерпретации стандарта, где он может состоять не из 8-ми бит...
напоминаю про своё обещание поставить + тому, кто назовёт хоть одну платформу\компилятор, где байт представляет из себя не 8 бит  

Архимед, тебя что, на Гугле забанили?   Таких систем, оказывается, было много: 

http://en.wikipedia.org/wiki/Byte#Meanings

Только, похоже, они все уже умерли.

вот еще тут посмотри:  
http://en.wikipedia.org/wiki/36-bit_word_length

archimed7592, кто-то кажется немного ошибся, а? ;)

Что-то мне подсказывает, но программа уровня выше "hello world" на машинах, разрядность байта которых отлична от 8, будет работать несколько иначе, чем на остальных машинах. Начнем с того, что передача данных отличных от текста между 9-ти битной и 8-ми битной машинами будет представлять собой "определенную" сложность.

На сколько я понял из последней ссылки начиная с IBM System/360 (анонсированой 7 апреля 1964 г) была введена практика на использование "слов", разрядность которых является степенью двойки. В то же время язык программирования Си был разработан в 1972 году. Так как нынче основной софт пишется на С/С++, то можно предположить, что мало кто отважится без крайней необходимости создать платформу, разрядность байта которой будет отлична от 8 бит, так как возникнет серьезная несовместимость. Причем не только программная. Или я неправ?

Имхо, все эти выкрутасы с типами в стандарте Си ни к чему хорошему не приводят. Имхо, это был компромис. Чего только стоит sizeof(short) == sizeof(int) на 16-ти битных платформах (по крайней мере, в Borland C++ 3.1 под DOS) и sizeof(int) == sizeof(long) - на 32-х битных (windows и *nix). А что будет иметь тогда разрядность 128 или 16 бит на 128 битной платформе?

Когда создаются структуры платформонезависимых файлов приходится вводить свои типы, типа UINT32, UINT16, UINT8... Думаю, не помешало бы ввести в Си на уровне стандарта дополнительные типы, например __int8, __int16, __int32, __int16b, __int32b, __int16l, __int32l (b - означает big endian, l - little endian)... Чтобы программист без введения конфигурируемых типов гарантированно имел доступ к нужному количеству разрядов в нужной последовательности.

ёп-та... скока плюсов то ставить... рука отсохнет  

Daevaorn, я не утверждал обратного... я просто захотел услышать от людей, сталкивались ли они в реальной жизни с такими системами... я имею ввиду не в музее/интернете видели, а именно программировали под них... ну да ладно, обещание своё выполню 

Hurricane++
nickless++

Добавлено через 13 минут и 35 секунд
для этого нужно использовать унифицированный способ сериализации/десериализации... правда, лично я, не стал бы заморачиваться и писать такую сериализовалку... что же касается существующих... boost::serialization - хз, как она с такой проблемой справится...

такая вещь реализованна в том же boost на уровне "работает почти везде"... но, по сути, что из себя должен представлять __int8 на платформе с 9-ти битным байтом? а что __int9 на пл. с 8-ми битным байтом? тогда уж вводить __int1, __int2 и пр., но, блин, в случае, если модным станет "скока хачу, стока битов в байт и положу", толку от этих типов будет не многим больше, чем от char, short, int, long, etc... насчёт l/b-endian: эт вообще гиблое дело...

all, а вот попробуйте на секундочку представить, каково станет программировать, если даже с малой долей вероятности нельзя будет предположить кол-во бит в байте, размер short/int/long/long long/new_int_type, порядок следования байт в слове(endianess)... ну и как перспективка? ;)

Не знаю как будет на 128 битах, а с 64 уже сейчас весело, винда использует модель LLP64, а *никс/мак - LP64.
Разница между ними - в LLP64 sizeof(int) = sizeof(long) = 4, sizeof(long long) = 8, а в LP64 sizeof(int) = 4, sizeof(long) = 8, и в обоих случаях sizeof(int) != sizeof(pointer)


Пожалуй было бы удобно, плохо только что очень уж много вариантов, особенно если учесть еще mixed endian и int64.  



ИМХО если кто до сих пор использует такие платформы - пусть сам и мучается  


Ужасть...  

я извиняюсь, а как его учесть можно?  
ну вот на x86 с big-endian я сделаю __int32l x = 5... и чо это будет?  

Ну например добавить еще __int32m, __int64m итд  А вообще он вроде тоже уже не используется.


На x86 little-endian ;) Я думаю такие типы можно было бы использовать для типов, которые предпологается записывать на диск/передавать куда-нибудь. Например в порограмме везде используем нативный int, а перед записью пишем его в __int32l и компайлер сам переставляет байты как надо, а мы сидим и наслаждаемся жизнью.  

ну не суть ;)


ради этого? сомнительная выгода... хотя чем меньше велосипедов присутствует на уровне компилятора/стандарта, тем меньше придётся их изобретать обычным смертным  

А кто сказал, что sizeof(void*) должен быть равен sizeof(int)? Имхо, отсюда все грабли лезут при портировании линуховых прог с x86 на x86_64 - то что многие были уверены в том, что sizeof(int) == sizeof(void*). А выяснилось другое: sizeof(long) == sizeof(void*).
А вот разработчики винды пошли по пути наименьшего сопротивления. Вот только не уверен, что именно он окажется более эффективным с точки зрения использования ресурсов процессора. Имхо, зачем тогда нужен тип long int, когда есть int того же размера?


Я именно про тоже. Нет никакого смысла в циклах и прочих внутренних вещах программы юзать всякие __int64l и __int64b. Это сильно скажется на быстродействии на "неродных" архитектурах. Но вот при формировании структур данных, записываемых в файл, такие типы очень бы пригодились.

Может ты имел в виду, "чем больше велосипедов присутствует на уровне компилятора/стандарта, тем меньше придётся их изобретать обычным смертным"?   


Кстати. Что-то мы отвлеклись от темы, вам не кажется?   

Это сообщение отредактировал(а) bsa - 25.5.2007, 10:17