Хочу чтобы разрядность конкретного псевдонима типа была постоянной при переходе с платформы на платформу. 

Не хочу "зоопарка" типов с различной разрядностью, не хочу беззнаковых типов. Экономия памяти таких масштабов (скажем, 1 млн. 32-битных целых против 1 млн. 8-битных - целых 3(!) МБ памяти) имела смысл в 70-е. Но не сейчас. А проблем слишком много.

Хочу один целочисленный знаковый тип фиксированной разрядности. 32-битный. Назовём его Int. Я не представляю зачем нужны целые числа фиксированной разрядности больше чем 2147483647. Да, я в курсе, про размер указателей в 64-битных системах. Но, во-первых, мне не нужен прямой доступ к памяти. Во-вторых, пускай (если кого "припрёт") для этих целей используется отдельный тип данных (Pointer), неприводимый к моему Int.

В качестве послабления дарую  возможность иметь встроенную / библиотечную длинную арифметику. BigInt.

Итого: Int (signed 32-only), BigInt (можно библиотечно), Pointer (только, если язык для системного программирования).

Из того, что мне известно. Haskell почти укладывается со своими Int/Integer, но хотелось бы чтобы Int таки имел фиксированную разрядность, а не covers at least the range [ - 2^29, 2^29 - 1]. Oberon-07 с единственным 32-битным INTEGER, длинная арифметика библиотечно.

Но писать-то приходится на... сами_знаете_чём. В качестве компромиса можно форсировать использование только 32-битных знаковых целых. Но сторонний код... Переполнения... Хорошо если в языке есть механизм, позволяющий конролировать арифметические переполнения... Всё равно - не то.  

А что думаешь ты, %username%?

Где зоопарк-то кроме C и C++? В Java и .NET размеры всех примитивных типов прибиты гвоздями, плюс строгие правила по поводу потери точности: без явного приведения типов int в short не запихнёшь. Динамические языки сплошь и рядом используют целый тип с плавным перетеканием в длинную арифметику. А в системном языке в любом случае нужен будет полный набор int|uint{8,16,32,64}, потому что API и протоколы.

Что в этот раз ты высосал проблему из пальца.

(отредактировал, было "short в int")

Это сообщение отредактировал(а) Void - 18.7.2010, 18:44

а те кому надо - представляют. 

kemiisto, юзайте питон, там одни тип int - бесконечной разрядности.

бесят такие темы, когда люди пишут "зачем ххх" не понимая зачем оно надо.

Видели! Это не я сказал!  


Погоди, погоди. Во-первых, примитивных типов и там, и там больше одного. В Java поменьше будет, т.к. нет беззнаковых. НО! Зачем язык усложнять, если оне не актуально. Ладно для системных ЯП. А тут... Чего огород городить со всякими явными приведениями типов, checked/unchecked и т.п.?


Вот это фуфло полное, по мне. Когда оно там перетечёт не знаешь. Всё-таки 32-битные пусть будут.


 

Добавлено @ 18:54

Ну-ка, расскажи!


И феерическая производительность.  Нет уж, спасибо.


Реальный сценарий, где нужны целые числа фиксированной размерности больше, чем 2^31 в студию!

Это сообщение отредактировал(а) kemiisto - 18.7.2010, 18:54

Чем тебе C# не системный ЯП со своим unsafe? А Java была спроектирована в те времена, когда так разбрасываться памятью, как ты предлагаешь, было нельзя, особенно на кофеварках.

Кстати, ещё один тип понадобится в любом языке — это массив байтов. А раз есть массив, значит и байт должен быть. Можно конечно его сделать неарифметическим типом. Но над такими вещами в мэйнстриме не слишком давно задумываться стали.

Вот теперь я понял...



Надо менять API и протоколы!  

kemiisto, вы на каком языке пишете? php и js? вот и пишите себе молча



Есть такие области программирования, где надо работать с числами. конечной разрядности.

Бинарные протоколы. Там данные имеют заданную длину в байтах. Когда я смотрю код на джаве типа "x = ReadInt32()" мне становится как-то не по себе %)

Криптография, и прочие задачи где надо "ксорить и складывать дворды", причем беззнаковые и с переполнением (unchecked).

Упаковка данных в памяти. Бывают ситуации, когда данных сравнительно больше чем памяти. По этому их надо упаковывать так чтобы количество двоичных разрядов было близко к количеству бит.
Вообще любые оптимизации по памяти, за счет того что программисту надо потрудиться и указать подходящий размер типа.


вы вообще понимаете почему сейчас "популярен" int32 а не int16 как лет 15-20 назад?
вам в голову не приходило, что использование int32 на 64 разрядной машине - это снижение производительности?
а то что индекс массива может занимать больше 31 разряда? (понятие указатель вам наверное непонятно)


0. размер файла.
1. флаги. SOME_FLAG = 0x800000000000;
2. числа, большие чем 2^31. Вы умеете считать только до 2^31 ?
когда сделали Ip адреса 32разрядными, тоже думали что этого хватит
3. произведения чисел больших 100'000. вам вообще приходилось когда-нибудь чтонибудь считать? умножать например. причем считать точно, а не использовать вещественные с плавающей точкой.
4. однажды в одной игре (ММОРПГ) количество предметов хранили в signed int32, сервер был написан на С++ и работал на win32. Потом некоторые игроки накопили больше чем 2^31 предметов, они переполнились и пропали. Сервер перенесли на win64.

погуглите "__int64" и вы найдете применения int64



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

вообще это здравая мысль, абстрагироваться от размера типа

например надо хранить количество яблок в корзине. для этого совершенно не важны тип и размер переменной, лишь бы в нее можно было хранить значения от 0 до 1000

но для этого вводят новые типы, например apples_count_t, а не выкидывают из языка старые.

для начала можно написать
typedef int apples_count_t 
и использовать этот новый тип для хранения количества яблок

потом можно безболезненно провести оптимизацию по быстродействию под различные платформы

Кхм. Ну так не нравится, не ешь. #define int int32_t.

Во-первых, как уже резонно заметили, на современном процессоре в 64-битном режиме работы 32-битное число - это проседание производительности. Во-вторых три мегабайта - фигня в рамках одного массива. А сколько их может быть одновременно (строки тоже считаем, ведь так?)... Так вы предалагаете вообще глобально использовать 32-бит на инт. Интересно будет посмотреть, как люто бешенно выжирается память, когда _весь_ софт начнет так работать.

>Надо менять API и протоколы!

И пусть весь хедер вплоть до IP-заголовка поместится в Ethernet-кадр! :D

>Экономия памяти таких масштабов (скажем, 1 млн. 32-битных целых против 1 млн. 8-битных - целых 3(!) МБ памяти) имела смысл в 70-е.

В начале 90-х только к мегабайту ОЗУ подбирались, насколько я помню из Just For Fun-а:).

Добавлено @ 11:49
Abyx, а вот яблоки проще хранить и вкуснее уплетать за обе щеки в более других языках с динамической типизацией, по-моему.

Это сообщение отредактировал(а) djamshud - 19.7.2010, 11:49

алсо в современных языках с выводом типов в большинстве случаев не приходится думать о размерах типов чисел
например в F# по умолчанию int32

Fortran, Oberon, скоро будем на Scala.


Abyx, я не о системных ЯП говорю. Лады. Там мы вынужденны весь огород оставить. Но для прикладного (во всех проявлениях) программирования... Неужели оно нужно?


Не надо считать меня за дурака.


Приходило, гуглил. Это миф. Давайте пруфлинк.



1) Системная штуковина. См. выше.
2) Я же сказал: если нужны числа большие 2^31 для счёта, то в 99,999% нужна длинная арифметика. а не 2^63.
3) Мне приходилось считать и не такое. Опять же тут нужна длинная арифметика.
4) Больше чем 2^31 предметов??? Я правда это вижу? Или сон?


Вывод типов есть не во всех языках...

дайте пруфлинк что миф)
либо мы будем использовать префиксы для 32разрядных команд, либо мы будем юзать 64разрядные регистры и программно проверять переполнение и прочие флаги


производительность длинной арифметики, реализованной программно на порядки ниже чем аппаратное умножение двух int64 на 64-разрядной машине


Это вполне реальная ситуация. Имеются ввиду предметы 1 типа. Деньги например.

Добавлено через 1 минуту и 37 секунд

я же написал, во всех современных языках.
а то что вы юзаете всякое старье типа оберона с фортраном - ваши проблемы

Нет уж, товарисчъ Трололо. Заявление было Ваше, так что и пруф с Вас.


Блин. Я же говорю: в тех случаях, когдане хватает int32, задача в 99% случаев такая, чтои int64 не хватит. Придётся использовать длинную арифметику.  


Либо использовать длинную арифметику, либо проводить деноминацию.  


Ой, как толсто!  

Если речь об x86-64, то префикс REX как раз нужен, чтобы получить доступ к 64-разрядным регистрам.

радует одно: толку от это этой темы  - нет никакого, никто не побежит править языки

меня в CL, Scheme и Haskell всё устраивает, а С и С++ -- языки системного программирования, там видимо такое оправдано

В принципе упростить прикладные языки конечно можно, но:

1. Работать с "нестандартными" задачами на таком языке будет сложнее (а длинная арифметика будет неудобнее и в разы медленнее, что далеко не всегда приемлимо), т.е. теряется универсальность
2. Не, ну почему 32 бита?? Это сейчас, когда количество памяти сжираемой программами уже нередко превышает гигабайты? Ты же даже DVD до конца досмотреть не сможешь без длинной арифметики, не говоря уже о файлах, базах данных, и таких незаметных вещах вроде скорости сети (а 1GBit/s = 2^30 bit)
3. Как ты собираешься работать с текстом (UTF-8, UTF-16, UTF-32  ), массивами данных (просто byte array), графикой (пиксель = 3 цвета по 1 байту), музыкой (куча форматов), видео (еще больше форматов), сетью (а, ну да, всё перепишем), другими языками (их прийдётся тоже в топку), операционными системами (там системные языки, но вызывать-то их API как-то надо)...

Хотя чтобы скриптик наваять там, или страничку в вебе хватит, но... как раз там используемые языки уже всё упростили