ЯННП

Ну и ссылка на latex - это вообще жесть. Я что робот, чтобы это парсить?

А какие живые архитектуры остались, у которых не two's complement

Я что робот

Судя по юзерпику, да.

Сдаюсь =)

Ну и ссылка на latex - это вообще жесть.

В названии коммита есть номер пропозала. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html

Не совсем ясно какое вообще языку дело до этой кухни.

Вопрос от тех кто не в курсе

Это как-то влияет на кроссплатформенность?

Пока компиляторы для двух с половиной платформ на которых не two's complement доберутся до С++20, эти платформы уже помрут. Так что скорее всего никак.

И что это даст?

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

Тогда в чём профит от этого финта ушами?

А можешь перечислить эти 2.5 платформы?

Appolo Guidance Computer был one-complement.

Honeywell 316, CDC Cyber 18, возможно Honeywell CP-6. Honeywell'ы вроде бы где-то ещё используются.

Не хватает информации. Зачем это было сделано, что это даст?

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

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

что это даст?

Right-shift on signed integral types is an arithmetic right shift, which performs sign-extension.

two's complement

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

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

Теперь можешь быть уверен, что ~42 == -43!

В этом нет смысла. Никто никогда в здравом уме не использовал этот факт. Это UC в чистом виде.

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

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

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

Зачем она его не имеет?

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

Зачем она его не имеет?

Зачем — вопрос не ко мне. Я просто констатирую факт, что не имеет.

констатирую факт

Не вижу примеров с пруфами.

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

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

констатирую факт

Не вижу примеров с пруфами.

Пруфы были выше.

Какое-то говно 1969г. Пощади, человек-анекдот.

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

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

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

Какое-то говно 1969г. Пощади, человек-анекдот.

Какая разница, если

Honeywell'ы вроде бы где-то ещё используются.

Вроде бы, где-то, УГ 1969г. Ха-ха.

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

Расскажи, пожалуйста, что это и зачем оно.

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.

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

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

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. Можно, конечно, возразить, что такое представление сейчас наиболее распространено. Но, опять же, не благодаря новому си++ стандарту. Зачем он лезет в сферу, повлиять на которую не может по определению?

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

См. мой ответ на другой камент.

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

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

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

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

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

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

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

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

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

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

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

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

Нас рассудит только время.

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

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

Так это провал со стороны gpu.

Так какие тогда претензии относительно изначальной темы треда к с++?

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

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

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

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

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

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

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

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

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

Что мешает писать на си с классами там где нужно под новыми стандартами?

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

А это заслуга стандарта или развития компиляторов, более совершенной кодогенерации, оптимизации под новые процессоры?

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