Oberon space

Так в Обероне же нет DEF-файлов :-) Их синтаксис не определен.

Не понял  -как можно сделать болванку из дефа (в XDS) автоматом?

Цитата: Comdiv от Апрель 12, 2011, 11:59:24 am

По пустякам и конструкторов не надо.

Вы это к тому, что Оберон - язычек на пустячек? 

Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не  использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).

Есть две равноправные школы математики, в одной из которых ноль входит в натуральный ряд чисел, а в другой -- не входит. Так какую из этих математик использовать при определении НОДа, и почему именно её?

Подмена сущности вопроса - в обсуждении шла речь о том какое ОПРЕДЕЛЕНИЕ НОДа ПРАВИЛЬНО использовать в целях образования (если речь идет об учебниках общего назначения)... Тут ответ прост -первое (с нулем) - основные причины:

Разумеется, ваш пример (который на форуме) в расчет не берется - там речь о СУЩНОСТИ нод'а вообще не шла (по сути дела речь шла о куске кода иллюстрирующем проблему), однако вы снабдили его комментарием - о принадлежности Вирту, что меня , признаться , сильно позабавило. 

Не, ну здесь просто классический случай для туплы...

С чего вдруг? У меня в коде как раз минимум повторных присваиваний. Повторные присваивания возникают, как правило, при желании экономить временные переменные. Потому что после повторного присваивания переменная, скорее всего, будет иметь уже другой смысл. А желание такое возникает от отдельной секции VAR - поэтому такая секция есть зло

Ну блин. В крайнем случае - напишите вторую функцию, которая будет принимать существующую структуру и переинициализировать ее. Делов-то. Закроете тот жалкий 1% случаев, когда это действительно надо. Вообще не понимаю откуда такая боязнь скопировать структуру, тем более на стеке. В C++ копируется направо и налево. Не помню ни одного раза, когда это приходилось бы оптимизировать (убирать лишние копирования).

Ну да, массив, хитро инициализируется. Говорил же уже. Дайте реальный пример, когда "это" будет тормозить задачу.

напишите вторую функцию, которая будет принимать существующую структуру(массив) и переинициализировать ее. Делов-то. Закроете тот жалкий 1% случаев, когда это действительно надо.

Мне кажется, что в подобных случаях изначальная проблема в правильной декомпозиции.

Код: [Выделить]

int a, b;
if (условие)
   int a = ...
   f();/*общий код*/
   a;
else
   int b =...
   f();/*общий код*/
   b;


Цитировать

Цитировать

Если, конечно, не пытаться повторять плюсовую семантику с конструкторами копирования и т.д.

Потому я и написал, что можно обойти. А теперь про шутки, которые неизбежно вылезут.

Цитировать

struct S {int a,b};
s = S{s.b, s.a};

Хе-хе. А вот здесь мы имеем не инициализацию, а присваивание. Сильно разные вещи. Здесь всегда будет копирование. Оно здесь будет даже если вы напишите на оригинальном обероне по всем правилам - с объявлением временной структуры, ее инициализацией и последующим копированием.

Цитировать

s = f(s);//А вот тут даже умный компилятор не знает как без накладных расходов не допустить ошибок в общем случае, прийдётся выдумывать другие хитрые механизмы.

Аналогично. Это присваивание.

Цитировать

S f(S s, int i) { return {s.b + 1, s.a / (i - 1)} }
S s = S{1, 2};//1
try {
  s = f(s, 1);//2
} catch {
    s = f(s, 2);//программист вправе ожидать, что до присваивания s всё ещё имеет 1-е значение.
}

Аналогично. Это присваивание.

Значит, я неправильно понял Вашу мысль. Думал, что Вы имели ввиду, что X x = f()-> X x;_f(x) будет всегда, в том числе и для повторного присваивания, а на самом деле будет так  X y;_f(y); x = y;
Да только это мало чего меняет в плане производительности, потому как кол-во повторных присваиваний может сильно превысить кол-во первых.
И понятно, что в приведённых примерах будет копирование в любом случае. Дело-то не в этом, а том, что при новой фишке, копирование и перерасход памяти должны выполняться вообще всегда при присваивании для простого компилятора без подвохов. А при явных механизмах программист сможет избежать этого там, где это нужно и возможно. Для циклов разница может быть большой.

Цитировать

Цитировать

Потому что несколько переменных могут зависеть от общих временных данных.

Ну и объявите эти временные данные здесь же, не в секции. В чем проблема-то?

В том, что временные переменные не должны делать вид, что они глобальные и занимать место там, где они не нужны.

Цитировать

бывает нужен более сложный алгоритм чем однострочник, и тут уж нужна процедура, объявленная до переменной, и, следовательно, появляется возможность размазывания.

Цитировать

Ну правильно. Все процедуры будут объявлены до переменной и до секции. Где размазывание? Тут на самом деле более интересная проблема: если инициализировать вызовом функции, то как обеспечить, чтобы функция не обратилась к этой же переменной модуля.

Я, конечно, имел ввиду более привычную схему. Конечно, можно всё перевернуть вверх дном, но как Вы сами заметили, это не решение, а только замена задачи.

Цитировать

Цитировать

Код: [Выделить]

struct Stack {int count, int s[N]};
Stack s;
s.count = 0;;
Структура инициализирована или нет?

Ошибка компиляции. Должна быть проинициализирована в точке объявления.

Разумеется, вопрос не об этом, а о смысле.

Цитировать

Да, не надо писать такие процедуры. Если надо установить новое значение уже объявленной - пожалуйста, пишите a = f(). Да, в данном случае для a (объявление/инициализация/присваивание) накладные расходы при прочих равных будут больше, согласен. Зато есть гарантия, что структура не останется проинициализированной наполовину.

Иногда и бывает нужно проинициализировать наполовину, а то и практически на нуль, как со стэком или, например, при чтении из потока, к которому возвращаешься время от времени, да ещё при этом используешь прочитанную ранее часть структуры. И правильнее говорить не о гарантиях инициализации, а о гарантиях заполненности чем-то.

Или вот ещё пример
f(int a[][]) {
    for (int i = 0; i < len(a, 0); i++) {
      for (int k = 0; k < len(a, 1); k++) {
          a[k] = i + k;
      }
 }
}
И ещё раз спрошу, если скорость не важна, зачем вообще статические данные?