Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 31

(пост ненависти)
Приведенный код не вызывает никаких подозрений у рядового разработчика, привыкшего к практике использования в качестве индексов переменных типа int или unsigned.

А КТО В ЭТОМ ВИНОВАТ?????? КТО ОБЪЯВИЛ, ЧТО ИНТ НА 64-ПЛАТФОРМЕ БУДЕТ 32-БИТНЫМ А?????

НЕНАВИСТЬ НЕНАВИСТЬ НЕНАВИСТЬ НЕНАВИСТЬ НЕНАВИСТЬ НЕНАВИСТЬ НЕНАВИСТЬ
Всего голосов 24: ↑11 и ↓13-2
>> А КТО В ЭТОМ ВИНОВАТ??????

У Microsoft был вариант сделать int 64-битным. Вероятно они взвесив все за и против, решили выбрать меньшее из зол.

>>НЕНАВИСТЬ НЕНАВИСТЬ

Боюсь, что в случае, если бы int был 64-битным, то «НЕНАВИСТЬ» была бы также справедлива :-).

Более того, вот Intel в Itanium отказался от совместимости, а проблемы все-равно остались.
Всего голосов 7: ↑6 и ↓1+5
Если бы инт был 64-битным, это было бы естественно для платформы. 16 бит на 16-битной платформе, 32 на 32-битной, 64 на 64-битной. Но нет, из соображений совместимости тупого кода тупых хомячков с новыми системами, которые за краткие годы своей жизни зазубрили, что инт — это от -2 миллиарда до +2 миллиарда, похерили последнюю логичную вещь, которая была в Си.
Всего голосов 9: ↑6 и ↓3+3
Вы же правильно пишете, именно из соображений совместимости. Опыт Itanium с отказом от совместимости был неудачным, поэтому выбрали совместимость. Вот очень хорошая статья 64-Bit Programming Models: Why LP64? с ответом на вопрос «Почему?».
Всего голосов 2: ↑2 и ↓0+2
Вот потому и ненависть. Потому девиз «совместимость» означает, дословно, следующее: «криворукие программеры писали так херово, что в новой системе их код не будет работать, так что мы изуродуем систему так, что криворукие программеры смогут писать дальше так же, а все остальные идут на йух и терпят, потому что это их проблемы, что они не криворукие».
Всего голосов 5: ↑3 и ↓2+1
Все правильно и полностью согласен. Только вот не «криворукие» программеры, а «обычные» программеры (обычные — это те, которых большинство). Понятно, что если бы писали все программисты хорошо, то проблемы бы не было. Однако к сожалению большинство программистов пишет плохо, и игроки рынка вроде Microsoft и Intel вынуждены под это подстраиваться.
Всего голосов 4: ↑2 и ↓20
Программист, который закладывается на размер инта и порядок байтов платформы — криворук. Можете считать это признаком (достаточным условием).
Всего голосов 3: ↑2 и ↓1+1
Нет мотивации писать «прямо» — нет и соответствующих результатов. Вы боретесь с ветряной мельницей, она так и будет крутиться.
Комментарий пока не оценивали0
Если бы инт был 64-битным, это было бы естественно для платформы. 16 бит на 16-битной платформе, 32 на 32-битной, 64 на 64-битной. Но нет, из соображений совместимости тупого кода тупых хомячков с новыми системами, которые за краткие годы своей жизни зазубрили, что инт — это от -2 миллиарда до +2 миллиарда, похерили последнюю логичную вещь, которая была в Си.
Ну, в стандарте си как бы не указывается, что длина int == битности платформы. То, что Вы указываете на их равенство — это как раз дело привычки. И к переносимости ПРАВИЛЬНО написанного кода это мало отношения имеет. А вот другое дело, что (это в том числе про правильно написанный код) нельзя эти типы и вообще целочисленную арифметику использовать для индексации массивов, операций с указателями итд итп. Для этого есть стандартные переносимые механизмы и типы, но опять же, ни к длине целого, ни к битности платформы прямого отношения не имеющие.
Всего голосов 2: ↑2 и ↓0+2
Многие стандартные приемы арифметики указателей предпологают что sizeof(void*)==sizeof(int)
Сейчас они собираются это поломать — и это я считаю неправильным.
Всего голосов 5: ↑3 и ↓2+1
единственный коммент по существу, согласен с Вами.
Комментарий пока не оценивали0
еще бы добавил о выравненности адресов относительно машинного слова, коим инт всегда был, отсюда и это ограничение которое вы озвучили.
Комментарий пока не оценивали0
1) Это давно поломано;
2) Эти приёмы арифметики давно нестандартны и использовать их — неправильно, т.к. эти приёмы непереносимы. Для этого есть size_t, ptrdiff_t и прочие приёмы, правильные и переносимые;
3) Возмущаться по поводу обратного — это можно сказать как то же самое, на что я сам отвечал:
из соображений совместимости тупого кода тупых хомячков с новыми системами, которые за краткие годы своей жизни зазубрили, что sizeof(void*)==sizeof(int) бла бла бла
В таких областях надо глядеть вперёд, в будущее, а не цепляться за старые костыли и привычки.
Всего голосов 4: ↑3 и ↓1+2
и как же вы собрались смотреть в будущее если все по старому остается, я думаю должно быть ясно что такие решения как оставить int 32 бита только для того что бы старый софт работал на новых платформах, разве это взгляд вперед? И в чем костыль если есть определенная схема которая выглядит по меньшей мере логичной, по большей упрощает написание таких низкоуровневых вещей как драйверы?
Всего голосов 1: ↑0 и ↓1-1
Я имел ввиду, что давным-давно правильным является НЕ использовать прямые типы для адресной арифметики, индексов массивов и т. п. Также никогда не было хорошим тоном предполагать длину любых типов. А если писалась сколько-нибудь потенциально переносимая программа — то вообще это было ошибочно. Тем более, что стандарт си никак не определяет конкретную длину типов.

Есть способ стандартный, одобренный и общепринятый писать переносимо между любыми платформами, в том числе разной битности, не оглядываясь на длину int и прочего и прочего. Отрицать эти способы и говорить «но ведь все привыкли, что int = битности, int = машинному слову и правильнее поэтому эту традицию оставить» — это бессмыслица какая-то и как раз это скорее делалось всё время «только для того что бы старый софт работал на новых платформах».

Правильный способ — не потакать привычкам, а отучить делать неправильно. Тогда вопросы о несовместимости разных размеров int будут просто бессмысленны, всё станет красивым и переносимым и будет всем счастье.

В драйверах нельзя что ли использовать size_t и ptrdiff_t?
Всего голосов 1: ↑1 и ↓0+1
Вообще соображение странное. Насколько я помню, int всегда был «стандартным размером целого» на данной платформе. Когда я переезжал с Borland C++ 3.1 на Windows, переход с 16-битного int на 32-битный воспринимался совершенно естественно.

И для меня (пока не разработчика под 64-бит платформы) сюрприз, что int не стал 64-разрядным. Как-то неожиданно и непонятно.
Всего голосов 2: ↑2 и ↓0+2
На самом деле, совершенно нету разницы сколько байт занимает int, если ваш код написан одинаково (т.е. все программисты считают, что размер int 4 байта или, например, 8).

Если вам не нравится, как сделали в компиляторе, добавьте
#define int __int64

в настройки проекта…

Всего голосов 2: ↑1 и ↓10
Ну Вы отмочили…

Если скучно на работе, можно еще что-то вроде

#define true false

сделать.
Всего голосов 3: ↑3 и ↓0+3
Вы не поверите, но вполне себе есть платформы, где sizeof(int) = 8, а не 4.
Всего голосов 1: ↑1 и ↓0+1
Чем больше я смотрю на мир победившей совместимости, тем меньше мне в это верится.
Всего голосов 1: ↑1 и ↓0+1
Да за примерами далеко ходить не нужно — в gcc размер int зависит банально от тех опций сборки самого gcc, которые ему будут переданы. Не то, чтобы многие, но некоторые дистрибутивы linux вполне себе живут с sizeof(int) = 8.
Всего голосов 1: ↑1 и ↓0+1
я бы сказал большинство, потому как размер 4 породил бы много больше проблем.
Комментарий пока не оценивали0
дальше первого примера читать смысла вообще не имеет :)
они там не тот фейл описывают вообще :)
Комментарий пока не оценивали0
Большую часть вышеупомянутых проблем определяют все современные компиляторы, не говоря уже о средствах статического анализа.
Всего голосов 2: ↑0 и ↓2-2
Вы ошибаетесь.
Подробнее комментировать смысла не вижу. Можете попробовать сами.
Комментарий пока не оценивали0
теперь текстовые процессоры занимают десятки и сотни мегабайт, обеспечивая на такой же порядок большую функциональность

правда?
Всего голосов 2: ↑2 и ↓0+2
в первом случае да… размер стал больше
а вот функциональность это вопрос :)
Комментарий пока не оценивали0
Вы тоже считаете, что Word 2010 по возможностям находится на уровне моего любимого Word & Deed — помнит кто-нибудь такой?
Комментарий пока не оценивали0
Эх… Мощная штука была для DOS'а. Последнюю версию юзал 7.40, кажется. Потом перешел на Вынь и иже с ней.
Комментарий пока не оценивали0
Теперь поговорим о юнит-тестах.
bool FooFind(char *Array, char Value,
             size_t Size)
{
  for (unsigned i = 0; i != Size; ++i)
    if (i % 5 == 0 && Array[i] == Value)
      return true;
  return false;
}


Тут кстати та же самая ошибка используется unsigned int, который не обязательно size_t. Пишу я вам не для того чтобы указать на ошибку — просто надоел пиар Viva64 и PVS-Studio. Статьи о типичных ошибках OpenMP и «20 ловушек переноса Си++ — кода на 64-битную платформу» это хорошо, но повторять раз за разом одно и то же разными словами — не знаю как вас, а меня это раздражает.
Всего голосов 3: ↑1 и ↓2-1
Это пока назойливо кажется. А как припрет, так ой как хорошие посты будут. :)
C# в свое время тоже ругали на все лады, говорили что это очередное поделие никому не нужно и надоела яростная реклама Micriosoft. А сейчас пойди, скажи, что C++ рулит, а C# нет. :))
И в развитие темы. Пост стороннего человека «Воспоминания об одном портировании на 64 бита».
Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr