Zealint писал(а):
А, я понял. Я предполагал, что у нас должно было быть минимум три поля. А если тип данных int136?
Тогда так:
Код:
int136 operator + (int136 a, int136 b) {
int128 t = a.l + b.l;
Result.l = int64(t);
t = a.m + b.m + t>>64;
Result.m = int64(t);
Result.h = a.h + b.h + t>>64;
}
Zealint писал(а):
Поэтому я и хотел бы убить сразу двух зайцев: избавиться от лишних скобок и вынудить создавать правильные отступы, так как неправильные будут означать семантически иной смысл. Это не избавляет от других возможностей сделать код унылым, но хотя бы приближает к этому.
Я бы безоговорочно согласился с вами, если бы не засада с табуляциями, приводящая к тому, что либо визуальное представление может не совпасть с семантикой (если табуляция не равна 8), либо потеряется переносимость и универсальность (если наложить запрет на табуляции).
Zealint писал(а):
Каким будет преобразование int64 -> real64? А int32 -> real64?
int64 -> real64 - условно-безопасное.
int32 -> real64 - безопасное.
Zealint писал(а):
Yoda писал(а):
А если у вас таблица десятеричных чисел? А если двоичных чисел? Как раз 0 здесь совсем не лишний.
Разумно. А если перепутать «0» с «O»? Вы приводили это в качестве аргумента отказа от восьмеричного суффикса «o».
Поэтому я и говорю - префиксов быть вообще не должно, а суффиксы можно, но только не те, которые визуально могут быть легко перепутаны с цифрами. Т.о. суффиксов "l" и "I" тоже быть не должно.
Zealint писал(а):
Yoda писал(а):
Zealint писал(а):
Кстати, остаток от деления «математический» или «программистский»?
А в чём разница?
В математике остаток всегда положительный.
Да, точно, - у меня как-то в этом направлении мысль даже не повернулась. Интересный вопрос. Я думаю, это надо как-то стандартизировать, но как, пока не знаю. Программисты не берут остаток от деления отрицательных (или на отрицательные) чисел, по крайней мере я ни разу не сталкивался с такой необходимостью в своей практике и не видел такого кода на практике. Как вариант могу предложить следующее: постулировать, что оператор остатка работает только с беззнаковыми типами по обоим операндам. Таким образом, не возникнет ни неоднозначности, ни разногласия между математическим и программистским представлением.
Zealint писал(а):
Yoda писал(а):
Тут вот какое дело. Бесконечный целый тип поддерживается не компилятором, а библиотеками, а это принципиальная разница. Поэтому, чтобы возводить в такую степень, надо сначала основание или показатель привести к бесконечному типу, тогда вместо встроенного возведения будет вызвана функция из библиотеки.
Ну так а большие константы на этапе компиляции тоже будут вычисляться посредством библиотек?
Да, т.к. постулируется, что этот тип должен входить в стандартные языковые библиотеки.
Zealint писал(а):
Yoda писал(а):
Я думаю, ** - будет достаточно понятно и удобно.
В одном из постов Вы жаловались, что нельзя поделить на указатель, так как получается комментарий. Не получится ли здесь так, что Вы будете умножать на указатель?
Не получится, т.к. для адресных операций не будет использоваться символ "*" (да и комментарии я хочу заменить). Вообще, это была крайне неудачная идея создателей языка. В моём синтаксисе это символ "@", что логично даже по его смыслу и названию.
Zealint писал(а):
Допустим, что резервировать мы не будем. Но нужна гарантия, что если в язык придётся добавлять новый тип, например, int256, то это не испортит чужих программ.
Я уже говорил, что скромно полагаю, что int256 никогда не будет широко востребован и необходимости в его добавлении в стандарт языка не потребуется. Но, думаю, на этот случай надежды надо возлагать на программистов и поведение самодельного int256 будет максимально адекватным, так что замена на встроенный тип не нарушит логику программы. Резервирование таких типов приведёт к тому, что эквивалентные по смыслу типы программистам придётся называть с нарушением логики.
Zealint писал(а):
Рациональные числа довольно часто требуются в научной среде. Ничем не меньше обычных целых. Maple даже с самого начала их воспринимает по-умолчанию. Написать там 7/5, то будет именно 7/5, а не 1.4 и уже тем более не 1.
Да, это понятно. Я думаю, в данной ситуации придётся пользоваться конструкторами. Логика следующая. Добавление рациональных чисел в качестве встроенных тащит за собой добавление целых неограниченного размера. Объявление их в качестве встроенных лишает их гибкости реализации. Таким образом, здесь должен быть некоторый компромисс. Нужно удобство записи, - придётся пользоваться специализированными средствами. Нужна скорость работы - придётся смириться с конструкторами.
Zealint писал(а):
Строка
Это встроенный тип, а не костыль. Полноценный тип с операциями конкатенации и сопутствующими. Числовые типы могут быть явно или неявно приводиться в строковый.
Вот тут у меня последние дни вкрадываться сомнения. Думается мне, что символьный тип всё же является лишним. По сути он не отличается от целочисленного и, более того, все эти свистопляски с
разными символьными типами (long char) и кривыми объявлениями типа L"Это строка", u8"Это тоже строка" на самом деле вызывают только раздражение. Вместо этого должна быть возможность инициализировать целочисленные массивы юникодовыми символьными строками. Например:
uint8 str1[] = "Это строка";
uint16 str2[] = "Это строка";
uint32 str3[] = "Это строка";
В первом случае массив чисел будет инициализирован кодовой последовательностью UTF-8, во втором - UTF-16, в третьем - UTF-32. Таким образом можно обеспечить 100% совместимость с недрами ОС Windows, не прибегая к кривым объявлениям, режимам компиляции Unicode и безумным макросам _T("...") для объявления строк. И ещё, любые символьные константы должны трактоваться как беззнаковые. Эта свистопляска с трактовкой char как знакового или беззнакового типа в зависимости от пожелания компилятора меня откровенно достала.
Операция конкатенации на этапе компиляции не вызывает проблем. Какие ещё операции касательно строк необходимо отразить в синтаксисе языка, мне пока не приходит в голову.
Zealint писал(а):
Желательно наличие для этого типа регулярных выражений, позволяющих искать или генерировать нужную подстроку, выполнять самые разнообразные замены и подстановки.
Это легко делается на уровне библиотек.
Zealint писал(а):
Строка должна уметь переводить себя в разные кодировки. Как это будет выглядеть, дело другое, но должна. Дело в том, что язык, видимо, придётся делать с использованием utf-8, других вариантов я не вижу. Строка по умолчанию тоже utf-8, но выводить её в файл, возможно, придётся в 1251 или 866, а то и в другие однобайтовые распространённые форматы. Я считаю, что даже если это не делать встроенным в язык свойством строки, то это должно как минимум входить в стандартную бибилиотеку.
Я сейчас склоняюсь к мысли, что надо постулировать, что стандартной для языка является кодировка UTF-8. В конце концов, другие кодировки рано или поздно отомрут. Перекодирование в другие кодировки можно выполнять системными библиотеками. Чтобы не возникало накладных расходов на частое преобразование констант, я вижу такой выход. Необходима концепция безопасной функции, её главной особенностью является независимость результата от окружения. Таким образом компилятор может вызвать безопасные функции на этапе компиляции и подставить результат в код. Правда, пока что есть нюансы с реализацией таких функций применительно к строкам.
Zealint писал(а):
Спорный вопрос о том, нужны ли типы, определяющие время и дату.
Я думаю, что время должно быть не встроенным типом, а стандартным библиотечным.
Вход
Регистрация
FAQ
Поиск
