Zealint писал(а):
Yoda писал(а):
Код:
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;
}
Ну вот, если теперь временно закрыть глаза на смешивание знакового и беззнакового типов (int64(t) может "вдруг" стать отрицательным), то как всё-таки компилятор догадается, что мы хотим использовать ADC?
Смешивание типов в данном случае не играет никакой роли, - операции сложения и вычитания двоичных чисел тождественны для знакового и беззнакового типов.
Что касается ADC. Вот перевёл компилятор умножение в последовательность машинных инструкций. Сначала загрузки операндов, затем инструкция MUL. Вы же не переживаете, как компилятор догадается, что результат умножения хранится в регистрах DX:AX. Почему? Потому что это его святая обязанность – помнить, где находятся источники данных и куда помещаются все компоненты результата. В данном случае компилятор точно так же
обязан помнить, что старшая половина результата сложения хранится в бите переноса, а значит для последующего сложения с битом переноса он легко может использовать инструкцию ADC. Я не вижу проблем (кроме, может быть, чисто технических), связанных с такой обязанностью.
Zealint писал(а):
Yoda писал(а):
либо потеряется переносимость и универсальность (если наложить запрет на табуляции).
В упор не пойму, как здесь потеряется переносимость и универсальность. Мы заявляем, что есть только два символа-разделителя: перевод строки и пробел.
Потеря переносимости и универсальности в том, что вы не можете взять произвольный plain-text редактор и писать/править исходники.
Zealint писал(а):
Yoda писал(а):
Как вариант могу предложить следующее: постулировать, что оператор остатка работает только с беззнаковыми типами по обоим операндам.
Никак нельзя. В модулярной арифметике постоянно приходится брать остаток от отрицательных чисел. Потом нужно писать условие if ( x < 0 ) x += P, чтобы прийти к положительному остатку.
Если я не ошибаюсь, в модулярной арифметике любое число, чтобы быть валидным, должно быть в диапазоне 0...P-1, то есть положительным. Откуда у вас взялись отрицательные числа?
Zealint писал(а):
Yoda писал(а):
Не получится, т.к. для адресных операций не будет использоваться символ "*" (да и комментарии я хочу заменить). Вообще, это была крайне неудачная идея создателей языка. В моём синтаксисе это символ "@", что логично даже по его смыслу и названию.
Я всё время произношу "собака" или "сволочь" на символ @. А один из моих преподавателей заставлял говорить "коммерческое эт", за что (хотя и не только за это) я перестал ходить на его лекции : )
Я не понял, – вы на этом основании возражаете против этого символа? Кстати, в английском языке не говорят "коммерческое эт" – слишком длинно для них. Обычно говорят просто "эт". Википедия утверждает, что его часто называют "атперсанд" или "штрудель". В общем, называйте, как хотите.
Zealint писал(а):
Не помню, говорил ли, но я предлагаю зарезервировать такие слова не для того, чтобы ими нельзя было пользоваться, а для того, чтобы ими можно было сделать ТОЛЬКО типы данных и определить для них ТОЛЬКО те функции и операции, которые есть для встроенных типов. Таким образом, программист может писать что угодно, но интерфейс класса обязан соблюдать. Таким образом, мы вынуждаем программистов быть адекватными, потому как если просто надеяться на это... : ) я давно перестал верить в адекватность многих людей.
Вообще говоря, невозможно сделать абсолютно защищённый язык. В данном случае я вижу как минимум две проблемы.
1. Как вы планируете наложить соответствующие ограничения? Я не вижу адекватного механизма.
2. Интерфейс в данном случае почти не важен, важна как раз реализация, а её никак ни ограничить, ни проверить.
Zealint писал(а):
Yoda писал(а):
Думается мне, что символьный тип всё же является лишним.
Он лишний. У меня его даже и нет в концепции.
...
Ещё символьные константы нельзя переводить в числовые и логические типы.
Поясните, пожалуйста, мне кажется между двумя этими фразами есть противоречие. Вы пишете, что символьный тип лишний, но его нельзя переводить в числовой. Это как?
Zealint писал(а):
Yoda писал(а):
Операция конкатенации на этапе компиляции не вызывает проблем. Какие ещё операции касательно строк необходимо отразить в синтаксисе языка, мне пока не приходит в голову.
Обращение к символу str[ i ]. Правда, не факт, что данная операция будет иметь сложность O(1)... или тогда потребуется дополнительная память для хранения смещений каждого символа, если у них размер не одинаковый.
Обращение к символу – не часть синтаксиса, а библиотечная (или на крайний случай встроенная) функция. Чтобы обращение к символу работало за постоянное время, необходимо работать с 32-битными символами, другого варианта я не вижу.
Zealint писал(а):
Yoda писал(а):
Необходима концепция безопасной функции, её главной особенностью является независимость результата от окружения.
В смысле, эта функция которая не получает на вход никакую небезопасную функцию или переменную и не обращается к глобальным по отношению к ней данным?
Безопасная функция - это функция, которая удовлетворяет следующим критериям:
1. Она не использует глобальных переменных.
2. Она не имеет статических данных.
3. Она вызывает только безопасные функции.
По сути, концепция безопасных функций лишает адептов функционального программирования почвы под ногами
.
Zealint писал(а):
Комментарии должны быть нескольких видов.
На мой взгляд, только двух видов.
Zealint писал(а):
Должны быть многострочные комментарии, когда комментарием считается всё, что между парой специальных символов (аналог /* */ в C). Однако здесь есть важный момент: при вложенном комментировании завершающей скобкой (*/) должна быть НЕ ПРОСТО ПЕРВАЯ комбинация, а та, которая подходит по уровню вложенности.
Это называется просто "вложенные комментарии". Кстати, стандартом C/C++ вложенные комментарии запрещены (это меня тоже бесит). Насколько я понимаю, это ограничение обусловлено тем, что закрывающая часть может встретиться внутри строки, типа "blah */ blah". На самом деле, аргумент нелепый. Я думаю, что подобная ситуация решается очень просто - добавлением экранирующего символа в закрывающую пару, например так: "blah *\/ blah". Ранние стандарты языка С никак не оговаривали вложенность и большинство компиляторов с древних времён решали этот вопрос как им было удобней, в т.ч. при помощи опций, указывающих, какой вариант использовать. Конечно, этот бардак должен быть прекращён, и конечно в пользу вложенных комментариев.
Zealint писал(а):
Другой вариант избежать подобной нелепости – сделать по аналогии с Pascal, когда есть два вида многострочных комментариев и можно вкладывать друг в друга эти разные виды, не порождая подобных трудностей при грамотном анализе правильность скобочных последовательностей.
Это также ошибочное решение. Оно позволяет без проблем использовать не более одного уровня вложенности и плодит сущности без необходимости.
Zealint писал(а):
Код:
/* Коментарий*/ */ */ */
Код
/* Ещё Коментарий*/ */ */ */
Здесь компилятору очевидно, что последняя скобка в 1-й и 3-й строке закрывающая.
Нет, как раз компилятору это совершенно не очевидно. Оба варианта должны трактоваться как ошибки.
Zealint писал(а):
Иногда программист специально оставляет комментарий типа fixme или !!! или ??? (у каждого свой такой символ), так вот, было бы неплохо, чтобы компилятор выдавал предупреждение, если увидит такой комментарий:
Код:
if ( a > b ) {
return c; // fixme: разобраться! Возвращается что-то не то.
}
Нет, не согласен. В С/С++ для замечаний предусмотрены директивы препроцессора. Комментарии для того и делаются, чтобы не вызывать никакой реакции со стороны компилятора.
Zealint писал(а):
Ещё один вид комментариев, который
в редких случая может пригодиться: комментарии, которые распространяются на множество строк от одной строки до другой. Например:
Код:
begin-global-comment
Тут можно писать что угодно
end-global-comment
Между begin-... и end-... можно писать что угодно, это будет восприниматься как комментарий. Можно задать вопрос: а чем это отличается от /* */ ? Да по сути ничем, кроме приоритета и гарантии того, что между этой парой лексем может быть абсолютно что угодно, даже комментарии более низкого уровня. Здесь даже не будут раскрываться команды макроподстановки (см. ниже) - аналог verbatim в LaTeX.
Абсолютно не согласен. Это по сути аналог паскалевского подхода. Макроподстановки в комментариях и так игнорируются, а для того, чтобы внутри не воспринимались другие комментарии, надо просто соблюдать правильную вложенность.
Zealint писал(а):
Есть такая вещь, как генерация документации из кода. При этом комментарии становятся частью документации.
Тут, я думаю, стоит разделить понятия. С точки зрения
компилятора комментарии документации ничем не отличаются от других комментариев. Более того, для всякого рода визуальных средств и генераторов документации
внутри комментариев можно создать любую непротиворечивую структуру и соглашения. Так, вижуал студия создаёт кучи своих блоков ориентируясь на комментарии вида:
Код:
//{{AFX_MSG(CApp)
//}}AFX_MSG
Но с точки зрения стандарта языка подобных блоков не существует - это просто комментарии.
Вход
Регистрация
FAQ
Поиск
