Zealint писал(а):
Мне что-то не нравится, но я пока не могу понять, что именно. Могли бы Вы написать оператор сложения полностью правильно для int72 (на любом языке, который можно понять без лишних пояснений)? При этом, если Вы пользуетесь int128 для промежуточных результатов, то нужно описать и его.
int128 не нужно описывать, это должен быть последний встроенный тип.
Код:
int72 operator + (int72 a, int72 b) {
int128 t = a.l + b.l;
Result.l = int64(t);
Result.h = a.h + b.h + t>>64;
}
Zealint писал(а):
Совершенно верно, однако есть визивиг (wysiwyg) редакторы для TeX, которые оставляют скрытым plain-text, лежащий в основе.
В данном случае ТеХ - это язык программирования, а визивиги - среды разработки. Таким образом, собственно языком является неудобоваримое текстовое представление.
Zealint писал(а):
Вы не ответили на мой вопрос о том, какие по-Вашему символы в UTF-8 следует считать устоявшимися. Или вопрос некорректен?
А я почём знаю? Я даже не уверен, что изменения не могут затронуть первые 32 символа. Я бы по крайней мере, попробовал бы там тоже навести какое-то подобие порядка. Пожалуй, можно утверждать, что точно устоялись символы с кодами 10, 32-126. Даже символ с кодом 13 - порождение зла, его то с одной стороны приткнут, то с другой, то вообще выкинут, то изобретают специальные моды открытия файла для работы с ним.
Zealint писал(а):
Yoda писал(а):
Но здесь есть своя засада - символ табуляции!
Я предлагаю запретить символ табуляции и назначить на эту кнопку что-то другое в моём редакторе, а ещё считать данный символ синтаксической ошибкой. Ведь, например, в C++ многие символы будут синтаксической ошибкой, и если в новом языке добавить в этот список tab, то ничего по сути не изменится. Просто 9-й символ будет восприниматься таким же запрещённым, как, например, 31-й.
Это нереально и единственно, к чему может привести, это к куче негативных отзывов. С моей точки зрения было бы правильней стандартизировать: табуляция - это ВСЕГДА 8 позиций. Но даже в этом случае обязательно будут недоразумения.
Zealint писал(а):
Можно альтернативный вариант: во внутреннем plain-формате скобки для блоков кода есть, а во внешнем формате их нет.
Вот опять вы смешиваете. Внутренний формат - это и есть язык.
Zealint писал(а):
Я считаю, что нужно запретить неявное преобразование типов.
16-битные целые числа к 32-битным тоже явно приводить?
А если есть типы, определённые пользователем, с тем же видом отношений между ними?
А если есть необъемлющие типы, которые было бы удобно приводить автоматически? Например, функция вывода сообщений ожидает указатель на константную строку символов, а у вас собственный тип данных строк, нужно ли позволить неявное приведение или каждый раз надо писать:
Код:
cout << static_cast <const char *>(mystr);
?
А если учесть, что результатом умножения всегда является удвоенный размер, нужно ли явно приводить результат к тому же типу после умножения?
А если вспомнить, что даже операции с плавающей точкой как правило приводят к потере точности (а то и к переполнению), нужно ли после каждой операции над числами типа float приводить результат к float?
Zealint писал(а):
А теперь мы делаем иначе:
Код:
Int32 a = 10 + (65536*65536);
Каким должен быть типа произведения в скобках? Должен ли компилятор догадаться по размеру результата, что тут нужен тип более высокий, чем int32? Если да, то получаем ошибку неявного приведения типов. Если нет, то будет переполнение и это вряд ли то, чего хотел бы программист (возможно, он допустил опечатку - и компилятор должен что-то ему сказать).
Моя точка зрения состоит в том, что константы не должны иметь точно указанного размера, как например 1ULL в C/C++, т.к. они всегда используются только в каком-то контексте. Любые константные вычисления компилятор должен производить с бесконечной точностью и по результату приведения к конечному требуемому типу выдавать ОШИБКУ, если число выходит за целевой диапазон значений.
Zealint писал(а):
Более сложный вопрос
Код:
Int32 a = 10 + (65536*65536)/65536;
Это выражение будет ли вычислено правильно? Формально, тип ответа сходится по размерности, но промежуточные результаты выходят за его рамки. Что должен делать компилятор? Чем по-умолчанию должно быть число 65536?
В варианте, предложенном мной выше никакой неоднозначности не возникает, всё будет посчитано корректно.
Zealint писал(а):
Чтобы не было подобных проблем, можно попытаться сделать следующее.
Ваш вариант более запутанный. А суффиксы - это зло, они усложняют логику и вынуждают программиста явно держать в голове не только сами расчёты, но и размер результатов после каждой операции.
Zealint писал(а):
на удивление почти всегда программа получалась быстрее и проще (именно «и», а не «или»). Мистика.
Никакой мистики.
Zealint писал(а):
Записи типа
Код:
double a = .5
double a=5.
запретить и выжечь калёным железом. Меня лично они чем-то сильно задевают (это полностью субъективная оценка, но разумных обоснований я не слышал и не придумал).
Полностью согласен. Разумное объяснение: запись типа .5 усложняет лексический анализ, т.к. при встрече символа "." в потоке требуется проверка следующего символа, не число ли. Если язык допускает нумерованные поля, то потребуются ещё более сложные телодвижения для анализа, необходимо ли трактовать a.5 как пятое поле структуры "a" или переменную "a", за которой следует константа с плав.тчк.
Zealint писал(а):
Теперь что делать с константами в других системах счисления? Вот здесь как раз суффиксы и будут наиболее удобным решением: b, o, h. Например,
Цитата:
int16u a = AB'CD'h // шестнадцатеричное
int16u a = 1010'1011'1100'1101'b // двоичное, не может быть конфликта с шестнадцатеричным из-за суффикса b, так как тут нет суффикса h
Всё верно. А префиксную запись типа 0xABCD я бы запретил. Да и восьмеричную систему счисления тоже запретил бы. Только два суффикса - b и h.
Zealint писал(а):
Есть одна проблема, как не перепутать имя переменной ABCDh с шестнадцатеричной константой? Я думаю, что апостроф нужен перед суффиксом всегда, то есть константа должна иметь вид ABCD'h, без апострофа это будет литерал.
Никаких апострофов перед суффиксами. Неоднозначность решается просто, - любое число должно начинаться с цифры. 0ABCDh - число, ABCDh - переменная.
Zealint писал(а):
Теоретически, можно использовать даже произвольное основание int32 a = 123_5, что будет означать 123 в пятеричной системе, а int32 a = 123_3 будет уже ошибкой компиляции. Но, мне кажется, поддержка произвольной системы счисления на уровне языка не нужна...
Много лет назад у меня была аналогичная идея, причём с точно такой же записью. И я также пришёл к выводу о полном отсутствии такой необходимости в рамках компилятора. Хотите системы счисления - пишите мультисистемный калькулятор, а для языка программирования это явно избыточно.
Лирическое отступление по поводу типизации. Дэн Гроссман, ведущий на курсере курс "Языки программирования" от Вашингтонского университета, считает (и я в этом с ним полностью согласен), что деление на слабую и сильную типизацию некорректно, ибо нет чёткого определения такого разделения. В каждом языке есть свои правила приведения типов, что можно приводить неявно, а что нельзя. С/С++ являются не слабо, а
плохо типизированными языками. Например, в С проблемой является не смешение целочисленного и булевого типов, а
отсутствие булевого.
Вход
Регистрация
FAQ
Поиск
Там просто пишешь текст, потом выделяешь и не хватаясь за мышь нажимаешь комбинацию клавиш, в результате быстро получаешь богатое разнообразие форматирования.
.