The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.
Что непонятного во фразе сделать по аналогии с extern "C" { ... }?
Ладно, я по твоему профилю вижу, что зря ввязался в этот спор. Хабранутый специалист по всем вопросам с 8к комментариев имеет единственное развлечение в жизни докапываться до людей.
Очень просто. Если в заголовке есть #pragma CPP20, то его содержимое считается как бы обрамлённым extern "CPP20" { ... } по аналогии с extern "C" { ... }. Каждое объявление в итоге получается внутри какого-то блока, который обрабатывается по правилам какой-то версии стандарта. Ну и они могут быть вложенными.
Прям так и хорошо? Все прям радуются удобству и стройности языка C++. И продолжают его использовать вовсе не потому что за это время было написано кода на триллиарды денег. Ну а новые версии стандарта просто так по приколу придумывают, ведь язык и так норм. Все так хорошо работает, что нужно под каждый компилятор программу на C++ подгонять, но всем это только в радость
Смысл то моей претензии в том, что вот на бумаге полезнейший тип с фиксированным размером, но на практике его использовать невозможно, потому что он непредсказуемым образом на разных компиляторах конфликтует с разным кодом. Этот тип совместим с каким-то произвольным типом, но при этом другие типы, которые имеют одинаковый размер на данном компиляторе (long и long long на GCC64) вдруг являются несовместимыми. Сделайте тогда уж типы с фиксированным размером отдельными типами вроде std::byte
И какая библиотека будет использовать тип, который даже непонятно каким будет на разных компиляторах? Проблема то в том, что даже нельзя написать дополнительный конструктор с int64_t , так как он на каком-то из компилятором может совпасть с long long, а на каком-то с long. Ведь это не отдельный тип, а псевдоним для какого-то рандомного типа
Раз вы переходите на личные оскорбления, то попрошу вас предоставить пруфы на "всего-навсего embedded различного сорта, DSP там всякие" не из прошлого века, где "int, и тип long, и тип long long — это всё 64-битные целые"
Я уже объяснил почему, чтобы было юзабельно и переносимо между компиляторами. Можете привести пример, когда при очевидном выборе между размерами типов что-то поломается? Написать в стандарте прямо, что если размеры примитивных типов совпадают, то они соместимы
Когда Вы используете extern "C" void f(int); или даже вставки ассемблера в C++ коде Вас почему-то не беспокоят инклюды (что показывает Ваше невежество).
И вообще для меня странен сам подход тянуть совместимость с несуществующими платформами.
Также считаю, что должно быть в исходниках что-то вроде #pragma CPP20 означающая, что вот это вот приложение/библиотека/единица трансляции должна компилироваться компилятором в режиме C++20. Тогда можно ломать обратную совместимость хоть в каждой версии.
В данном конкретном случае веселуха в том, что у первого типа размер 32, а у второго 64, и компилятор мог бы и догадаться, какой конструктор использовать
Какой-то громкий и непонятный заголовок. По сути то что они сделают? Добавят ядра для перемножения матриц, как тензорные ядра nVidia?
В C23 уже наложили ограничения на размер типов, C++ на очереди очевидно https://open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf
The rank of long long int shall be greater than the rank of long int, which shall be greater
than the rank of int, which shall be greater than the rank of short int, which shall be greater
than the rank of signed char.
Мало англоязычных площадок что ли?
Для твоего старья есть старый компилятор. Тебе C++23 нужен на этом?
Вот смотри, ты сделал заявление, которое не смог подтвердить и ещё решил меня пооскорблять. Поэтому я имею моральное право заявить, что ты брехло.
Что непонятного во фразе сделать по аналогии с
extern "C" { ... }?Ладно, я по твоему профилю вижу, что зря ввязался в этот спор. Хабранутый специалист по всем вопросам с 8к комментариев имеет единственное развлечение в жизни докапываться до людей.
Ну а заголовки без прагм (для обратной совместимости) могут определяться флагами компилятора, как это сейчас делается
Очень просто. Если в заголовке есть #pragma CPP20, то его содержимое считается как бы обрамлённым
extern "CPP20" { ... }по аналогии сextern "C" { ... }. Каждое объявление в итоге получается внутри какого-то блока, который обрабатывается по правилам какой-то версии стандарта. Ну и они могут быть вложенными.Это Ваш ответ на мой вопрос?
Прям так и хорошо? Все прям радуются удобству и стройности языка C++. И продолжают его использовать вовсе не потому что за это время было написано кода на триллиарды денег. Ну а новые версии стандарта просто так по приколу придумывают, ведь язык и так норм. Все так хорошо работает, что нужно под каждый компилятор программу на C++ подгонять, но всем это только в радость
Внезапно и на GCC32 тоже с int и long
Смысл то моей претензии в том, что вот на бумаге полезнейший тип с фиксированным размером, но на практике его использовать невозможно, потому что он непредсказуемым образом на разных компиляторах конфликтует с разным кодом. Этот тип совместим с каким-то произвольным типом, но при этом другие типы, которые имеют одинаковый размер на данном компиляторе (long и long long на GCC64) вдруг являются несовместимыми. Сделайте тогда уж типы с фиксированным размером отдельными типами вроде std::byte
И какая библиотека будет использовать тип, который даже непонятно каким будет на разных компиляторах? Проблема то в том, что даже нельзя написать дополнительный конструктор с int64_t , так как он на каком-то из компилятором может совпасть с long long, а на каком-то с long. Ведь это не отдельный тип, а псевдоним для какого-то рандомного типа
Раз вы переходите на личные оскорбления, то попрошу вас предоставить пруфы на "всего-навсего embedded различного сорта, DSP там всякие" не из прошлого века, где "int, и тип long, и тип long long — это всё 64-битные целые"
Я уже объяснил почему, чтобы было юзабельно и переносимо между компиляторами. Можете привести пример, когда при очевидном выборе между размерами типов что-то поломается? Написать в стандарте прямо, что если размеры примитивных типов совпадают, то они соместимы
Когда Вы используете
extern "C" void f(int);или даже вставки ассемблера в C++ коде Вас почему-то не беспокоят инклюды (что показывает Ваше невежество).И вообще для меня странен сам подход тянуть совместимость с несуществующими платформами.
Также считаю, что должно быть в исходниках что-то вроде
#pragma CPP20означающая, что вот это вот приложение/библиотека/единица трансляции должна компилироваться компилятором в режиме C++20. Тогда можно ломать обратную совместимость хоть в каждой версии.Так я и говорю, что хорошо бы стандартизировать такое
В данном конкретном случае веселуха в том, что у первого типа размер 32, а у второго 64, и компилятор мог бы и догадаться, какой конструктор использовать
Или предлагается кастить вручную для каждого аргумента каждой функции? А то мало ли как там в каком компиляторе оно реализовано