OberonCore

Это был не надуманный пример. В Дельфе действительно много стандартных процедур было написано именно в стиле передачи структур или строк через стек копированием (предопределенная переменная result). И использовались они в коде сплошь и рядом...

Нафантазировать можно много чего... Зачем смешивать разные механизмы - передачу через стек и по ссылке? Одни ругаются, что низкий уровень недоступен, но когда предлагается прозрачный сиснтаксис, который абсолютно высокоуровнев, но позволяет программисту чувствовать и контроллировать то, что происходит в сгенерированном коде, другие начинают кричать, что "мало автоматизации"...
Много ли компиляторов поддерживают такую оптимизацию? Где гарантии, что код, написанный с надеждой на эту оптимизацию, на другом компиляторе не потеряет в производительности раза в два (а такое реально)? Так я вижу, что происходит, и знаю, что где бы не откомпилировал программу, при выполнении будет происходить одно и то же.
Опять же, многие ли из компиляторов С++ не имеют каких-нибудь общеизвестных ошибок, именно из-за непоследовательности и навороченности языка? Те же возможности можно было реализовать и гораздо более стройно, просто приняв принцип "одна возоможность - только один способ ее использовать..."

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

Произвольных.

Всё верно, но вывод надо сделать противоположный. Вот язык C# разрешает возвращать структуры. Конструктор структуры "new Data()" как раз эту самую структуру и возвращает. Непроинициализированных структур в C# не бывает. Результат - потеря производительности, которую я вчера продемонстрировал в сообщении от: "Вт Май 02, 2006 2:11 pm".

По поводу возвращения структур из функций можно привести пример с комплексными числами в C#. Естественно, процедура в которую комплексные числа передаются и забираются по ссылке работает быстрее чем функция из которой возвращается копия структуры комплексного числа. Я когда-то об этом ещё на РСДН-е писал. Там народ предложил дожидаться когда Микрософт свой JIT компилятор до ума доведёт.

> ... то их возвращали бы везде, где не лень, потому что форма
> записи действительно удобнее. Отсюда лишние тормоза, т.к.
> безобидная запись a := GetSomeRec() (а таковые в той же Дельфе
> пишутся обычно сплошь и рядом) вызывает два лишних
> копирования - сначала в стек внутри процедуры, потом из стека в
> ту переменную, которой присваивается...

А чем вот этот вариант (извиняюсь за С, синтаксис языков Вирта пока знаю плохо, никак руки не дойдут):
struct flags {
char flag_a;
char flag_b;
};

flags GetFlag()
{
...
return MyFlag;
}

Хуже (тормознее) чем скажем какая-нибудь:
double GetMagicNumber() {return magic;}

?

Кроме того, мне кажется что если уж класс - это тип определенный пользователем, то и разрешенное множество операций с этим типом должно быть таким же как и с базовыми (предопределенными) типами.
Просто для того чтобы не множить сущности.

Он тормознее, чем работа по ссылке:
void GetFlag (flag &f),
PROCEDURE GetFlag(OUT f: Flag)
потому что здесь процедура напрямую пишет в поля выходного параметра, в то время как в вашем случае она сначала копирует 8 байт (с учетом выравнивания структуры) в стек инструкцией return, а затем еще раз - из стека для присваивания какой-либо переменной после возврата из функции. На малой структуре разница невелика. На большой - в разы.
Если, конечно, не помечтать об суперумной оптимизации, которая когда-нибудь, может быть, появится

Это - мощная идея, у нее есть много плюсов, но есть и минусы... Так или иначе, в Обероне перегрузки операций и обобщенки нет. В большинстве случаев особых неудобств это не приносит. Даже тем, кто программирует численные алгоритмы и др. научные вещи - а среди этого контингента КП&ББ распространен пока больше всего. Притом переходит на него этот народ, именно устав "долбаться" с С++.

Да, но по крайней мере в C/C++ работа (изменение значения) по ссылке - плохая идея с т.з. синтаксиса. Т.к. отличить просто параметр от того что функция должна будет изменить, просто не реально при использовании такой функции.
Например:
GetFlag(MyFlag);
Ничем не будет (синтаксически) отличаться от
SetFlag(MyFlag);
Хотя это ПРИНЦИПИАЛЬНО разные действия (SetFlag(flag f)).

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

Каков синтаксис использования таких конструкций в Обероне/КП?

> после возврата из функции. На малой структуре разница невелика.
> На большой - в разы.
Ну так. Большую никто копировать и не будет. Хотя конечно единообразие подхода к структурам любого размера, это конечно хорошо.

А зачем вообще забивать себе голову такими вещами? В С++, например, вообще нет понятия стека, это всего лишь детали реализации. Любой профессиональный программист, естественно, представляет себе реализацию того или иного языкового механизма, но зачем искусственно ограничивать мышление?



Это ты про оберон? Не согласен, я уже говорил. Полный контроль над сгенерированным кодом есть в С и с большими оговорками в С++.



Даже борланд это умеет. Правда не без бзиков (помню ему было принципиально пишется ли Object o = getObject() или Object o(getObject())).



Знаешь, все имеет свою цену. Так вот, такие "гарантии" не стоят менее удобной записи и неинициализировнных переменных. Я бы даже сказал, что это вообще несравнимые вещи.



Ошибки кодогенерации у популярных компиляторов надо поискать. Хотя я сталкивался и на VC6 (один раз) и на борланде (несколько раз).



Это очень ограничивает. Я не хочу мыслить в терминах типичной машинной архитектуры при решении моих прикладных задач. Мне это никак не помогает. Все bottle-neck'и на моей практике упирались не в копирование объектов или т.п. "особенности реализации", а в используемые алгоритмы и ограничения системного API. И решались эти проблемы соответственно.

Почему бы не рассматривать такую "хитрую" инициализацию как повод к редизайну?



Значит для шарпа твой пример некорректен и говорить о каком-то perfomance fault'е не приходится.



Ты не понял. В C# твой пример не имеет смысла, т.к. нет необходимости передавать неинициализированную (инициализированную по умолчанию) структуру куда-либо, можно сразу вернуть проинициализированную нужными (недефолтовыми) значениями.



Если это так, то это очень неплохой совет, по сравнению с ручной работой, которую никто не оценит (какова вероятность, что bottle-neck будет именно в этом?).

Я настаиваю на том, что такое утверждение некорректно без указания конкретного компилятора.



Уже давно появилась. VC7.1:

Этому есть вполне естественное объяснение. У такого контингента нет времени на изучение "особенностей" С++ и нет возможности применить эти знания (на численных алгоритмах).

Не понял, поясни пример... Показываешь, что на каждую инструкцию приходится по одной машинной? Ну так лишняя инструкция возникает не в main, а при возврате значения из процедуры. И оптимизатор не поможет, т.к. код процедуры генерируется один, а контекстов, в которых она вызывается - много, и под конкретное присваивание ничего не подгонишь. Если только не inline...

Я специально пытался написать нетривиальный код, чтобы его не выкинул оптимизатор. Однако он его все равно выкинул. Тогда я подумал - зачем пытаться обмануть оптимизатор, когда и этот пример сам по себе показателен. И запостил сюда.



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

Да, согласен, в С++ это не красиво. Как в Обероне? В Обероне и в том, и в другом случае принято передавать структуру по ссылке, только "ссылки" бывают разные: VAR, IN, OUT, что позволяет явно указать, для чего передается ссылка на данные - для их изменения, только для чтения (тогда изменение внутри процедуры будет запрещено) или подчеркнуть то, что на входе данные могут быть неопределенными (но чтение все равно не запрещается).
PROCEDURE GetFlag(OUT f: MyFlag);
PROCEDURE SetFlag(IN f: MyFlag);
Таким образом, вызов двух таких процедур тоже "синтаксически никак не будет отличаться" (GetFlag(f), SetFlag(f)) не будет он отличаться и технически. А уже семантику операции должно выражать ее название Get/Set - сам синтаксис языка тут не причем.

Вобщем, Vlad дело в следующем. Всё началось с того, что Вы заинтересовались почему в оберонах компилятором не контролируется обязательная инициализация переменных перед их использованием и сослались на языки Java/C#, в которых это делается. Я Вам показал какой ценой (в потере производительности) там (в C#) это достигается. Цена эта очень высокая. Да, конечно, контролировать обязательную инициализацию хорошо, но не любой же ценой! Уверен, что если когда-нибудь изобретут более приемлемый способ контроля, то он будет использован и в оберонах.

Насчет записи - для меня Обероновская кажется гораздо удобней. Единый стиль - все выходные данные, сколько бы их ни было, через OUT-параметры. Возвращаемые значения - либо указатели, либо некие числовые данные. Все по полочкам...
Неинициализированных переменных такие гарантии не стоят. Но они с ними никак и не связаны - я про то вообще и не говорил. Отсутствие защиты от неиниц. п. - действительно недочет. Возможно, если Ominc уже взялись расширять Оберон, то надо было в КП позволить в VAR-объявлениях указывать значения инициализации для полей, а явно не инициализированные забивать нулями. Или ввести до BEGIN секцию INIT, где всем необходимым полям/переменным можно присвоить результат каких-либо выражений, а остальные компилятор забьет нулями... На Ada можно посмотреть, опять же, в качестве примера.
Хотя лично я не разу не напарывался на ошибку неинициализированной переменной. Просто сам стиль мышления, какой пропагандируется в Оберонах - прежде чем написать строку кода, обеспечь все предусловия.

Если не ошибаюсь, собственно в Обероне и Обероне-2 нет IN и OUT. Они появились только в КП.


А зря. Логичней было бы IN - только чтение. OUT - ТОЛЬКО запись. VAR - и то и другое.


Хех... Эдак оправдать можно и синтаксис вроде: ++a-=b+++++c;
Сказать, что мол названия переменных должны отражать сущность производимых операций... Ну в крайнем случае добавить коментарий.

На самом же деле НАМНОГО удобней (по крайней мере с т.з. чтения исходников. Чужих исходников.) Был бы синтаксис требующий при передаче параметров явно указывать для чего они передаются. Т.е.:
GetFlag(OUT: f) (* OUT - будет произведена запись в f *)
SetFlag(IN: f) (* IN - f будет прочитана, но точно не будет изменена *)

Причем возможно стоило бы сделать блоки ввода и вывода. Вроде:
MyProc(IN: a,b,c OUT: d,e,f)
Чтобы сразу при вызове функции(процедуры) было ясен набор входных параметров и набор того что она выдаст.

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

Фактически сейчас КП мало в этом плане отличается от С++, где тоже можно передавать нечто только для чтения:
void SetFlag (const &Flag f);

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

Кстати, в языке C# ссылка out дополнительно означает, что запись в этот параметр нужно сделать обязательно. Хочешь - не хочешь, а в out параметр чего-то записать ты всё-равно обязан (хоть нули забить), иначе не скомпилируется. Вы к этому как относитесь? По моему это слишком сурово, лучше бы так: хочешь - записывай что-то в OUT переменную, а не хочешь - не записывай.


Правда, инкремент и декремент уж больно забавно будет выглядеть: INC(VAR: i, 10); DEC(VAR: j, 5);

Я мало что смыслю в том как устроены компиляторы, как их создают и как они работают, но логично было бы чтобы любая вновь созданая переменная изначально была в режиме "только запись" до тех пор, пока в нее что-нибудь не запишут. Как в переменную что-то записали (проинициировали), так она становится открытой и для чтения и для записи.

Если же из нее пытаются что-то прочитать до момента первой записи (инициализации), то должна выскакивать ошибка.

Только боюсь, что тут нужна будет какая-то рантайм поддержка. Какой-то аналог сборщика мусора (нечто что будет отслеживать таковые переменные), хотя может и ошибаюсь.

Могут быть ситуации, когда OUT-значение не должно быть изменено(грубо говоря, торчит какой-то внутри процедуры IF с параметрами в виде лог. выражения из входных параметров, и если оно истина, то выходное значение изменяется, если ложь, то нет), в этом случае запись в OUT - лишняя, бессмысленная работа. Причем в случае если OUT означает что из переменной читать нельзя, то мы ничего осмысленного туда записать не сможем. Т.к. чтобы не изменить OUT-параметр, мы должны были бы его вначале прочесть, а зетем записать в него тоже значение что и прочли.

Т.е. обязательность записи в OUT, если OUT у нас только на запись, не нужна. Более того - вредна.


VAR можно опустить.
Т.е. INC(i, IN: 10)
Либо INC(i,10) (* я не знаю как объявленя INC, если второй параметр тоже как VAR, то так пойдет, иначе же - нет *)

Т.е. по умолчанию подразумевается VAR.
Если типы доступа в объявлении процедуры и в её использовании не совпадают, то ошибка.

Можно конечно еще упростить (сократить) запись, введя правило что передача константы (10) автоматически (по умолчанию) приравнивается к входному параметру (IN). Но стоит ли плодить исключения? Не знаю...