LINUX.ORG.RU

История изменений

Исправление EXL, (текущая версия) :

Тоже беспокоит, там должен быть не больше uint16_t.

Дисплеи быстро набирают в разрешениях и через десяток лет могут вылезти за 65535. И Qt к этому будет полностью готов, в отличие от, например, X.Org.

В шестёрке будут наконец внедрять сильную типизацию, или останется везде int на все случаи жизни, даже там где требуется беззнаковый или explicitly-convertible тип?

Почитай эту тему, анон: QT -- размеры в int -- что за бред оО? Или я чего то не понимаю? (комментарий)

В Qt до версии 4 были unsigned в контейнерах, от которых отказались и перешли на использование signed-значений.

А сейчас проблема в том, что я не могу создать QVector больше 2Гб на 64-битной платформе, а std::vector могу.

Для контейнеров такого огромного размера требуется использовать что-то особенное. В той же Java, насколько я помню, тоже Integer в размерности местных структур данных, аналогичных QVector’у.

Исходная версия EXL, :

Тоже беспокоит, там должен быть не больше uint16_t.

Дисплеи быстро набирают в разрешениях и через десяток лет могут вылезти за 65535. И Qt к этому будет полностью готов, в отличие от, например, X.Org.

В шестёрке будут наконец внедрять сильную типизацию, или останется везде int на все случаи жизни, даже там где требуется беззнаковый или explicitly-convertible тип?

Почитай эту тему, анон: QT -- размеры в int -- что за бред оО? Или я чего то не понимаю? (комментарий)

В Qt до версии 4 были unsigned в контейнерах, от которых отказались и перешли на использование signed-значений.

А сейчас проблема в том, что я не могу создать QVector больше 2Гб на 64-битной платформе, а std::vector могу.

Для контейнеров такого огромного размера требуется что-то использовать что-то особенное. В той же Java, насколько я помню, тоже Integer в размерности местных структур данных, аналогичный QVector’у.