Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - kkkk

Страницы: [1]
1
Общий раздел / Странные битовые операции
« : Ноябрь 18, 2016, 03:52:59 pm »
Цитировать
видимо, return  (x > clip_box.x2) | ((x < clip_box.x1) << 2);
на обероне будет как-то так:
RETURN SYSTEM.VAL( UNSIGNED32, SYSTEM.VAL( SET, ORD( x > clipBox.x2 )) + SYSTEM.VAL( SET,  ASH( ORD( x < clipBox.x1 ), 2)));
А почему не так?
RETURN ORD( x > clipBox.x2) + ORD( x < clipBox.x1 ) * 4 Или я что-то упустил? Ещё я не припомню гарантий в описании, что ORD(TRUE) = 1, а ORD(FALSE) = 0, но иначе ORD для BOOLEAN не имел бы смысла.

В Си где только можно использую нормальную арифметику вместо битовых операций и не чувствую, что чего-то не хватает.

2
Кто-то считает это необходимым, кто-то - ненужным. Меня интересует техническая сторона, точней одна её деталь. Как эффективно совместить локальные записи и закрытые элементы. В идеале интерфейс не должен содержать информации о скрытых элементах записи, пусть и помеченных как скрытые. Это легко достигается в интерфейсе уведомительного характера, но составляет проблему в интерфейсе для компилятора, так так тогда полный размер записи становится неизвестным, что является препятствием для размещения на стеке.

Более или менее правильные намётки на решение я знаю, которое нужно даже не для этого, но оно довольно сложное. А какие костыли вам по душе?

3
Возвращаясь к нашим баранам. Зачем иметь локальные переменные в отдельной декларативной части? Есть какие-нибудь формальные причины, кроме "здесь так заведено"?
В первую очередь это самое простое из достаточных решений, вдобавок, близкое к генерируемому коду.
Стимулирует писать обозримые процедуры. Кстати, встроенные процедуры смазывают это, но нужны по другой причине.
Простое средство от дополнительных ошибок, связанных с перекрытием.

int i = 0;
func() {
a = i;
{
int i = 1;
b = i;
}
}

или ещё хуже

int i = 0;
func() {
a = i;
int i = 1;
b = i;
}
Подобные вещи дают сбои редко, но метко, как правило, при длительном развитии кода, особенно несколькими людьми.
Дополнительное веселье может начаться, если в языке есть перегрузка функций, тогда может не спасти и типизация при разнотиповом перекрытии.

4
Посмотрел на код, который выдает транслятор и впечатлился объемом по сравнению с тем, что мог бы написать непосредственно программист. С учетом того, что Оберон более низкоуровневый язык по сравнению с JS, что означает в среднем большее количество кода для выполнения той же задачи, то ситуация усугубляется. Можно долго дорабатывать транслятор, но вряд ли разрыв удастся свести к 0. В связи с этим возникает вопрос о назначении и применимости инструмента. По моему Алексей упоминал, что не исключает его использования для серьезных задач. Каких?

Страницы: [1]