Нужно было бы знать, что архитектура машины написала код?

В последний раз, когда я смотрел спецификацию языка Java, она содержала нелепую ошибку в разделе, посвященном упаковке целых чисел.

Integer a = 100;
Integer b = 100;

System.out.println(a == b);

Это гарантированно выведет true .

Integer a = 300;
Integer b = 300;

System.out.println(a == b);

Это не гарантирует печати истины . Это зависит от времени выполнения. Спецификация оставила его полностью открытым. Это потому, что упаковка int между -128 и 127 возвращает "интернированные" объекты (аналогично интернированию строковых литералов), но разработчику языковой среды рекомендуется поднять этот предел, если они пожелают.

Я лично считаю, что это как безумное решение, и я надеюсь, что они исправили это с тех пор (написать один раз, запустить где угодно?)

Иногда вам нужно беспокоиться.

Вы можете быть удивлены, когда эти низкоуровневые детали внезапно выскочат и укусят вас. Например, Java стандартизировал double как 64-битный. Однако Linux JVM использует режим «расширенной точности», когда значение double составляет 80 бит, пока оно находится в регистре ЦП. Это означает, что следующий код может дать сбой:

double x = fun1();
double y = x;

System.out.println(fun2(x));

assert( y == x );

Просто потому, что y принудительно выгружается из регистра в память и сокращается с 80 до 64 бит.

В Java и Python детали архитектуры абстрагированы, так что фактически более или менее невозможно написать архитектурно-зависимый код.

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

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

В C ++ и C правильное выполнение действий включает в себя отказ от предположений о int. Не помещайте указатели в int, и когда вы делаете что-либо с размерами памяти или адресами, используйте size_t и ptrdiff_t. Не рассчитывайте на размер типов данных: int должно быть не менее 16 бит, почти всегда 32, а на некоторых архитектурах может быть 64. Не думайте, что арифметика с плавающей запятой будет выполняться на разных машинах точно так же (стандарты IEEE имеют некоторую свободу действий).

Практически все операционные системы, поддерживающие работу в сети, предоставят вам способ справиться с возможными проблемы с порядком следования байтов. Используй их. Используйте языковые средства, такие как isalpha (), для классификации символов, а не арифметические операции с символами (что может быть чем-то странным, например EBCDIC). (Конечно, сейчас более обычным явлением является использование wchar_t в качестве символьного типа и внутреннего использования Unicode.)

Если вы программируете на Python или Java, интерпретатор и виртуальная машина соответственно абстрагируют этот уровень архитектуры. Тогда вам не нужно беспокоиться, работает ли он на 32- или 64-битной архитектуре.

То же самое нельзя сказать о C ++, в котором вам иногда придется спрашивать себя, работаете ли вы на 32- или 64-битной машине

Вам нужно будет заботиться о "порядке байтов", только если вы отправляете и получаете необработанные структуры C. по проводам, например

ret = send(socket, &myStruct, sizeof(myStruct));

, однако это не рекомендуется.

Рекомендуется, чтобы вы определяли протокол между сторонами, так что это не имеет значения архитектуры машин сторон.

В C ++ нужно быть очень осторожным, если вы хотите написать код, который безразлично работает на 32 или 64 битах. Многие ошибочно полагают, что int может хранить, например, указатель.

Зная, как все работает, будь то виртуальный машина работает, и как она работает на вашей платформе, или то, как определенные конструкции C ++ преобразуются в сборку, всегда сделает вас лучшим программистом, потому что вы поймете, почему все должно быть сделано именно так.

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

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

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

Короче говоря, нет. Вам не нужно знать низкоуровневые вещи, но никогда не помешает знать .

32-битная машина позволит вам иметь максимум 4 ГБ адресуемой виртуальной памяти. (На практике это даже меньше, обычно 2 ГБ или 3 ГБ в зависимости от ОС и различных параметров компоновщика.) На 64-битной машине вы можете иметь ОГРОМНОЕ виртуальное адресное пространство (в любом практическом смысле, ограниченное только диском ) и чертовски большой объем оперативной памяти.

Так что, если вы ожидаете наборов данных размером 6 ГБ для некоторых вычислений (скажем, что-то, что требует некогерентного доступа и не может просто передаваться по потоку за раз), в 64-битной архитектуре вы можно было просто читать его в ОЗУ и делать свои дела, тогда как в 32-битной архитектуре вам нужен принципиально другой подход к ней, поскольку у вас просто нет возможности сохранить весь набор данных резидентным.

С java и .net вам действительно не нужно возиться с этим, если только вы не занимаетесь очень низкоуровневыми вещами, такими как тидлинг бит. Если вы используете c, c ++, fortran, вы можете обойтись, но я бы рекомендовал использовать такие вещи, как "stdint.h", где вы используете окончательные объявления, такие как uint64_t и uint32_t, чтобы быть явным. Кроме того, вам потребуется сборка с использованием определенных библиотек, в зависимости от того, как вы выполняете компоновку, например, 64-битная система может использовать gcc в 64-битном режиме компиляции по умолчанию.