OberonCore

INC(IN: i,10 OUT: i);



Но, кстати, сразу понятно что происходит. Более понятно чем INC(i,10); особенно если не знаешь что такое INC.

Ты ничего не показал. Повторяю еще раз: твой пример применительно к C# бессмысленен, потому что единственный осмысленный пример использования неинициализированной структуры (который я могу придумать) - это передача ее "куда-либо" для инициализации. Однако в C# это не нужно, потому что можно сразу получить структуру "откуда-либо" в готовом проиниченном виде. Другими словами: "на любом языке можно писать как на фортране", только не надо претензий к тому, что это неэффективно.

P.S. Слово "инвариант" тебе о чем-то говорит? Как в обероне обеспечить инвариант структуры?

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



Кстати, сама идея разнесения объявления и инициализации способствует появлению неинициализированных переменных.



В С++ все проще - объявляй переменную там, где она нужна

На самом деле это на любителя. Указатели полностью не решают проблему и создают другие проблемы. Лично я на С++ предпочитаю возвращать все через возвращаемое значение, а не через параметры. Так нагляднее и проще выстраивать цепочки вызовов.

В VC8 такая поддержка есть.

Вы конечно правы, но на половину.

Рассмотрим пример.

Пусть есть следующая структура на языке C#:

Мы пишем свой инициализатор для этой структуры:

Пытаемся его скомпилировать, но не можем Компилятор ругается:

Исправляем код:

теперь всё компилируется. Но инициализация идёт два раза. В первый раз структура 'a' забивается нулями в "new Data()", и только потом она инициализируется числами 1, 2 и 3.

Хорошо, думаем мы, пусть это всё злой-плохой out-параметр. Напишем без него, вот так:

Пробуем скомпилировать, и опять, ёксель-моксель, не получается Компилятор ругается:

Исправляем код:

Теперь компилируется, но эта процедура-функция получилась ещё тормознее первой. В самом деле, сначала структура 'a' инициализируется нулями, затем значениями 1, 2, 3; а потом, она ещё копируется инструкцией return туда куда надо. Аплодисменты. Занавес.

Да, так уже лучше. А конструкторов (или списка инициализации) у структур в C# разве нет?



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

Циферки в комментариях:


В самую точку ! Конструкторы, конечно, есть. В них-то вся загвоздка. Если написать конструктор:

и инициализировать посредством него: g = new Data(1, 2, 3), то всё будет летать: t = 4.747 секунд, что быстрее чем с конструктором по умолчанию , объяснить почему g = new Data(1, 2, 3) работает быстрее чем g = new Data() - я не могу.

Вывод: для каждой структруры надо писать конструктор.

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

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

И в чем она заключается?

Диагностируются попытки использования непроиниченных переменных. В рантайме.

А примерчик можно?

/RTCu ? Но это довольно дорого. И работает только для локальных переменных. Или в 8-е что-то улучшили?

А если мы читаем данные или выполняем вычисления и заполняем поля структуры по ходу дела?

Аналогично. Там где это под моим контролем, стараюсь придерживаться правила:

ВЫХОД MyFunc(ВХОД);

Но так получается не всегда. Иногда функция должна вернуть несколько значений, но это еще можно обойти (возвращать через общюю структуру, сделать эти значения видимыми, реструктурировать программу так, чтобы данная функция должна была возвращать ровно одно значение). Но основная проблема в том, что например Win32 API сплош и рядом использует возврат значения через параметры (используя указатель), а в STL тоже в общем то обычная практика изменять нечто переданое в качестве параметра. Причем переданное в виде не указателя а ссылки. Например list::splice(iterator _Where,list<Allocator>& _Right,iterator _First);

+ код писаный не мною, а кем-то еще. В результате имеем в одном проекте не хилый зоопарк решений и подходов. Всё в куче. Что несколько раздражает и отвлекает.

В Обероне с этим чуть лучше - тут всё (кроме базовых типов) возвращается через параметры по ссыле. С одной стороны это единообразие (почти единообразие - таки возврат базовых типов через значение присутствует, и ясно впринципе зачем - чтобы можно было написать c := sqrt(a*a+b*b)), но с другой - единообразие в виде одного из наиболее невнятных (в плане синтаксиса вызова) механизмов, это не есть гут.

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

Отлично. Значит реализуемо.

Вопрос - насколько дорога такая поддержка?

Я не вникал в подробности. Просто код из VC6 (сгенерированный визардом) перестал работать

И что это меняет? rturn MyStruct(calc(), read());