Да, да, а ещё земляным червяком! Т.е. до сих пор есть в серверных процессорах команда "перепаковать число в форме для показа на девятисегментном индикаторе".

(Ответить) (Thread)

Во-первых, эти индикаторы были семисегментными (у некоторых - точка, восьмым сегментом). Во-вторых, десятичная арифметика нужна не только для индикаторов.

(Ответить) (Parent) (Thread)

А эта запись всем программистам понятна?

(Ответить) (Thread)

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

(Ответить) (Parent) (Thread)

С этой стороны как раз все в порядке. А вот когда на 32-битной машине пишут long, рассчитывая на его 32-битность, то на 64-битной как жахнет!

(Ответить) (Thread)

Зато у нас есть u_int64_t!

(Ответить) (Parent) (Thread)

Вот бы им еще и пользовались...

(Ответить) (Parent) (Thread)

Все ХОРОШИЕ программисты всегда пользуются uint64_t uint32_t и так далее...

(Ответить) (Parent) (Thread)

это первое, что мне вдолбили в голову на работе - никаких int'ов!

(Ответить) (Parent) (Thread)

Хорошие программисты не говорят ВСЕГДА.

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

(Ответить) (Parent) (Thread)

Те, кто думают о совместимости именно им и пользуются родимым.

(Ответить) (Parent) (Thread)

Да-да-да. А еще сыграет свою роль баг со временем в юниксе.

(Ответить) (Thread)

ну будем надеяться что к тому времени все уже успеют на 64-битное время перейти... (-:

(Ответить) (Parent) (Thread)

32-битным... До сих пор постоянно натыкаюсь на чудесное число 65535. И больше - ни-ни.

(Ответить) (Thread)

хм...

А что, в 64-битном GCC, sizeof(int) - тоже равен 4?

(Ответить) (Thread)

Ну да. LP64 называется.

(Ответить) (Parent) (Thread)

А вот не факт.
Если про С или плюсы говорить, то это ужасно плохо из-за pointer arithmetic, в которой получается нечто весьма странное, когда с одной стороны вокруг инты, а с другой -- пойнтеры всё-таки 64битные.

А в жаве или шарпе как-то довольно пофиг. Вот программист захотел сделать массив интов, точно зная, что они 32битные, потому что в стандарте так написано, ну и отлично, значит, ему больше не нужно пока. Иные программисты аж массивы шортов или вообще байтов делают, и ничего.
Стандартную библиотеку можно будет когда-нибудь переписать на лонги и совместимость замечательно сохранится, однако там, где нужно, будет всё хорошо. И интовые константы по дефолту считать лонгами. И тайп инференс очень уместно прокинет изменения дальше, там где он есть, конечно.

(Ответить) (Thread)

Дык курите стандарты, как говорится. Там ясно сказано, что пойнтер обязан помещаться в unsigned long, а то что он раньше помещался в int -- не более чем совпадение. (Да и stdint.h и limits -- вещи небесполезные).

(Ответить) (Parent) (Thread)

> пойнтер обязан помещаться в unsigned long

?

ISO/IEC 9899:1999 6.3.2.3.6.
Any pointer type may be converted to an integer type. Except as previously specified, the
result is implementation-defined. If the result cannot be represented in the integer type,
the behavior is undefined. The result need not be in the range of values of any integer
type.

(Ответить) (Parent) (Thread)

Хмм... Перепроверю; может быть, я и ошибся.

(Ответить) (Parent) (Thread)

Перепроверил для С++; был неправ, извиняюсь...

4 A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is
implementationdefined
[Note: it is intended to be unsurprising to those who know the addressing structure
of the underlying machine. ]
5 A value of integral type or enumeration type can be explicitly converted to a pointer.60) A pointer converted
to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type
will have its original value; mappings between pointers and integers are otherwise implementationdefined.

Особенно примечание понравилось -- "to be unsurprising" :)

(Ответить) (Parent) (Thread)

Когда Sony впервые выпустила библиотеки для PS3, то там, как это подобрает архитектуре нового поколения, все int-ы были 64-битными. Все честно-благородно. У всех девелоперов, бибилиотеки, естественно, поломались, а сроки поджимают, а консоль без игр никому не нужна. Поднялся такой шум, что Sony в следующем же релизе библиотек вернулась 32-битному int-у.
Так и живем.

(Ответить) (Thread)

УЖасы какие вы рассказываете.

(Ответить) (Parent) (Thread)

Это ещё что. Потом они другим глазом прищурятся хитро и добавят:

"А помните, когда вы на 64-битные компьютеры перешли, вы ещё long 32-битным оставили?"

И вот тут уже не будет нам прощенья. Разверзнутся инопланетные трансглюкаторы и громы с молниями поглотят нерадивое человечество.

(Ответить) (Thread)

Уверен, они и про PHP напомнят

(Ответить) (Thread)

Кстати, да, там при переходе с версии на версию (как сейчас помню) какие-то чудеса со знаковой "4-х байтной арифметикой" на 4х байтных машинах наблюдались :-)

(Ответить) (Parent) (Thread)

ׂПомню, в Watcom C при переходе с одной версии на другую поменяли тип char по умолчанию с signed на unsigned (или наоборот?) и с битовыми полями в структурах что-то подобное.

(Ответить) (Parent) (Thread)

Ой, я даже знаю, когда это будет! В 2038 году! :)))

(Ответить) (Thread)

Вы меня опередили! ;-)

... Оловянный пацифистик ...

(Ответить) (Parent) (Thread)

Ужос. Сколько программирую, а в инте 64битном необходимости не испытывал :)

(Ответить) (Thread)

Было дело. У нас в базе хранился размер файла. Оказалось, бывают видеофайлы больше 4 гигабайт.

(Ответить) (Parent) (Thread)

Не, ну никто не говорит что 64битные скаляры не нужны. У меня тоже размеры файлов и смещения в них хранятся в 64 битах, но это же не int, а совсем другой тип, ну и пусть он будет другим. А int пусть остается для тех вычислений, которые спокойно в 32бита умещаются. В 99% случаях этого хватит, а для остальных случаев есть другие типа.

Если бездумно сделать все intы 64битными, памяти слишком много зря будет расходоваться. Сплошные нули...

(Ответить) (Parent) (Thread)

Ну откуда ж у них более развитая технология, если они используют int там где важна разрядность? Да уже многие земляне types.h освоили!

(Ответить) (Thread)

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

(Ответить) (Thread)

Ну так наоборот еще хуже бы получилось. Берём старую программу (не такую, где всё посвящено обработке строчек, а чтобы считала что-нибудь) перекомпилируем – и из-за int и указателей рабочее множество возрастает почти в два раза. Что, скорее всего, означает, что она становится медленнее в два раза – в наше время CPU занят в основном тем, что ждёт память... И вообще по идее int – не самое большое, а самое быстрое (и не очень маленькое) целое в данной архитектуре. 32 бита на эту роль IMHO лучше подходят.

Мудаков, которые писали for (int i = strlen(s); ... или указатель на int кастили, конечно, жалко, но ведь мудак он всё равно найдёт способ как убиться, какой длины ты ему int ни приделывай. Так что войну с пришельцами мы и так и так проиграем :(

(Ответить) (Thread)

Софт для боевых роботов следует писать на ассемблере)

(Ответить) (Thread)

Лучше на brainfuck-е

(Ответить) (Parent) (Thread)

И сразу сдаваться.

(Ответить) (Parent) (Thread)

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

(Ответить) (Parent) (Thread)

Можно подумать, что int на хотя бы только 32-битных компьютерах совместимости добавляет :)) int - зло ;)

(Ответить) (Thread)

А вы подскажите мне, где можно почитать документацию по ассемблеру для 64 разрядных компов на русском?

(Ответить) (Thread)

И правильно сделали, что оставили.
Потому что пора понимать, что нефиг держать один int на все случаи жизни...

... и вообще думать на всяких там сях.

(Ответить) (Thread)

ждем начала 38-го года...

(Ответить) (Thread)

mysql> select UNIX_TIMESTAMP('2037-12-31 23:59:59');
+---------------------------------------+
| UNIX_TIMESTAMP('2037-12-31 23:59:59') |
+---------------------------------------+
| 2145909599 |
+---------------------------------------+
1 row in set (0.00 sec)

mysql> select UNIX_TIMESTAMP('2038-01-01 00:00:00');
+---------------------------------------+
| UNIX_TIMESTAMP('2038-01-01 00:00:00') |
+---------------------------------------+
| 0 |
+---------------------------------------+
1 row in set (0.00 sec)

а ведь 107-й год на дворе!

(Ответить) (Parent) (Thread)

Вообще-то с переходом на 64-битные процессоры программисты могут совладать используя Viva64.

(Ответить) (Thread)