LINUX.ORG.RU

В C++20 представление знаковых будет только в two's complement

 , ,


0

2

Странно, что никто не запостил новость. Ещё 24 ноября смёржили соответствующие изменения в текущий драфт стандарта.

Нет, signed overflow defined не сделали.

Ответ на: комментарий от Deleted

Теперь можешь быть уверен, что ~42 == -43! В случае с каким-нибудь int32_t это и раньше было гарантировано, но платформа могла не иметь такого типа, а теперь такое поведение гарантировано для всех знаковых целочисленных типов.

По ссылке есть и другие следствия вроде «The range of representable values for a signed integer type is $-2^{N-1}$ to $2^{N-1}-1$ (inclusive)».

Softwayer ★★ ()

two's complement

Блин, написали бы по-русски сразу: «дополнительный код».

«Но друг и учитель — алкаш в бакалее —
Сказал, что семиты — простые евреи.
Да это ж такое везение, братцы, —
Теперь я спокоен — чего мне бояться!»

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Softwayer

Теперь можешь быть уверен, что ~42 == -43! В случае с каким-нибудь int32_t это и раньше было гарантировано, но платформа могла не иметь такого типа

А что будет теперь, если платформа не имеет такого типа? Или предполагается, что все аппаратные платформы срочно будут подогнаны под новый стандарт крестов, меняющийся каждый год?

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

А что будет теперь, если платформа не имеет такого типа?

Ничего, он не обязан быть. Экспонента N для типов по-прежнему не фиксирована, есть только ограничения снизу (минимум 8 бит для char, 16 для int и т.д.).

anonymous ()
Ответ на: комментарий от anonymous

А что будет теперь, если платформа не имеет такого типа?

Ничего, он не обязан быть. Экспонента N для типов по-прежнему не фиксирована

Это понятно. Я про дополнение до 2.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Sutter:

Signed integers are two’s complement (JF Bastien) is the result of a courtroom drama in both WG21 (C++) and WG14 (C). After intense prosecutorial cross-examination, the witness finally admitted in both courts that, yes, all known modern computers are two’s complement machines, and, no, we don’t really care about using C++ (or C) on the ones that aren’t. The C standard is likely to adopt the same change.

anonymous ()
Ответ на: комментарий от aureliano15

Или предполагается, что все аппаратные платформы срочно будут подогнаны под новый стандарт крестов

А сколько существует таких платформ, на которых не two's complement и на которых реализован C++17?

anonymous ()
Ответ на: комментарий от anonymous

Sutter:

Signed integers are two’s complement (JF Bastien) is the result of a courtroom drama in both WG21 (C++) and WG14 (C). After intense prosecutorial cross-examination, the witness finally admitted in both courts that, yes, all known modern computers are two’s complement machines, and, no, we don’t really care about using C++ (or C) on the ones that aren’t. The C standard is likely to adopt the same change.

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

Но мой вопрос заключался в другом:

Теперь можешь быть уверен, что ~42 == -43! В случае с каким-нибудь int32_t это и раньше было гарантировано, но платформа могла не иметь такого типа

А что будет теперь, если платформа не имеет такого типа? Или предполагается, что все аппаратные платформы срочно будут подогнаны под новый стандарт крестов, меняющийся каждый год?

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

Можно, конечно, впихнуть в стандарт языка posix и x/open, x.org или какой-нибудь wayland, ieee754 и т. д., сделав язык, который будет поддерживать только ограниченное число десктопных unix платформ. Но зачем нужен такой язык? Имхо, стандарт языка не должен распространяться на то, за что язык по определению отвечать не может (как, например, внутреннее представление чисел). Для этого нужны другие стандарты для производителей оборудования. И мешать одно с другим, имхо, не только бесполезно, но и вредно.

Вот Softwayer написал, что де «раньше было гарантировано, но платформа могла не иметь», зато теперь «можешь быть уверен». Но ведь это же враньё. Теперь по сравнению с «раньше» ровно ничего не изменилось, потому что за представление знаковых чисел отвечает процессор, а не язык, а производители процессоров чихать хотели на стандарты языков, которых 100500. Можно, конечно, возразить, что такое представление сейчас наиболее распространено. Но, опять же, не благодаря новому си++ стандарту. Зачем он лезет в сферу, повлиять на которую не может по определению?

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

за представление знаковых чисел отвечает процессор, а не язык

За сложение чисел отвечает тоже процессор, а не язык. Пиши пропозал на выкидывание https://timsong-cpp.github.io/cppwp/n4659/expr.add из стандарта.

anonymous ()
Ответ на: комментарий от aureliano15

ровно ничего не изменилось

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

unC0Rr ★★★★★ ()
Ответ на: комментарий от anonymous

за представление знаковых чисел отвечает процессор, а не язык

За сложение чисел отвечает тоже процессор, а не язык. Пиши пропозал на выкидывание https://timsong-cpp.github.io/cppwp/n4659/expr.add из стандарта.

Как раз за операцию «+» и "-" отвечает язык, как и за типы данных, к которым эти операторы применимы. В процессоре могут быть команды add и sub, но работать они могут по-другому, и операторы «+» и "-" могут быть совсем не атомарными. Например, выражение a=b+c для x86 должно быть оттранслировано в общем случае в несколько команд: запись b и c в регистры, добавление регистра со значением «c» к регистру со значением «b» и с записью результата в регистр со значением «b» и затем запись регистра b в ячейку памяти a без модификации ячеек b и c. В некоторых случаях компилятор может оптимизировать этот алгоритм прозрачно для программиста, используя, например, одни и те же регистры для промежуточных результатов без записи каждого промежуточного результата в память, если этот результат потом не используется. И это есть компетенция компилятора, а значит имеет непосредственное отношение к языку, в отличие от внутреннего представления целых знаковых чисел.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

И это есть компетенция компилятора, а значит имеет непосредственное отношение к языку, в отличие от внутреннего представления целых знаковых чисел.

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

unC0Rr ★★★★★ ()
Ответ на: комментарий от unC0Rr

И не важно как именно эта гарантия реализуется, прямо в процессоре или наворачиванием дополнительных инструкций

Вот это как раз важно. Язык си и его продолжение си++ были сделаны для эффективной реализации на любом существующем железе, а не для эмуляции этого железа. Если нужна 100% совместимость в ущерб производительности, — используй яву, против которой я лично ничего не имею. Но зачем делать из си++ ещё одну яву? А сейчас эта тенденция налицо, и уже давно.

aureliano15 ★★ ()
Последнее исправление: aureliano15 (всего исправлений: 1)
Ответ на: комментарий от anonymous

На самом деле в C++ что-то ослабляли в модели многопоточности так, чтобы потоками могли считаться не только «привычные» потоки в ОС, но и воркеры на GPU.

anonymous ()
Ответ на: комментарий от anonymous

эффективной реализации на любом существующем железе

Это давно провалено. На gpu и прочих поделках обычные си и тд не работают.

Вот об этом комитетчикам по стандартизации и следует подумать, а не заниматься разной фигнёй.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Если нужен нормальный современный язык, используй C++2x/3x/Nx, если нужна производительность как у Си с классами, используй более старые стандарты.

его продолжение си++ были сделаны для эффективной реализации на любом существующем железе

Забавно читать такое, когда старый код при компиляции под стандартом C++11 внезапно становился быстрее, а C++17 - ещё быстрее, незатратные абстракции такие абстракции, производительный язык такой производительный.

unC0Rr ★★★★★ ()
Ответ на: комментарий от unC0Rr

Если нужен нормальный современный язык, используй C++2x/3x/Nx, если нужна производительность как у Си с классами, используй более старые стандарты.

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

Ivan_qrt ★★★★★ ()
Ответ на: комментарий от Ivan_qrt

Ничего, наоборот производительность улучшилась. Это ответ на предложение использовать яву, если хочется гарантий. Я имел в виду, выбирай C++ старого стандарта, коли тебе так важна производительность на гипотетической архитектуре, где гипотетическому компилятору под новый стандарт придётся вставлять дополнительные инструкции для сохранения гарантий нового стандарта на представление знаковых чисел, о которых речь в топике. И выбирай новый стандарт в остальных случаях, а не яву.

unC0Rr ★★★★★ ()
Ответ на: комментарий от Deleted

Стандарта. В 11-м появились move-конструкторы, в некоторых случаях стало создаваться меньше промежуточных объектов, на этом и экономия. В 17-м появилось тоже на этот счёт что-то. Так что достаточно старый код перекомпилить без изменений, чтобы он стал чуточку быстрее за счёт небольшого изменения семантики, безотносительно улучшений кодогенератора и прочего.

unC0Rr ★★★★★ ()