OberonCore

Если честно - это для меня большой сюрприз. Неинициализированные переменные - старинные сишные грабли, почему Вирт от них не избавился?

Не буду говорить точно, но это, скорее всего, определено не стандартом языка, а реализацией (ББ). Инициализируется в 0 только динамическая память и указатели. Если смотреть дизассемблированный код, то видно, как при старте процедуры инициализатор аккуратно затирает все локальные указатели, перепрыгивая через остальные поля...

А как?

В смысле как? Ошибка компиляции при попытке использования непроиниченной переменной (в идеале). Ну или обязательное забивание значениями по умолчанию (нулями) со стороны компилятора (если не хочется заморачиваться с анализом потока данных). Не, ну это ж просто дикость оставлять такой undefined behavior (так любимый С++'ми) в ЯВУ, претендующего на максимальную безопасность и простоту использования. В С/С++ это сделано умышленно из соображений эффективности с одной стороны и проблемами с определением факта использования неинициализированной переменной (адресная арифметика все карты путает) с другой.

Вот где собака зарыта...

Кстати, анализатор DevAnalizer выяляет такие косяки, как и многие другие...

И? Все нормальные ЯВУ (та же жаба, которая якобы калька с оберона) такого безобразия не позволяют.

Это уже костыли. Такие же, как и всякие отладочные примочки к сишным программам. А насколько трудно доточить компилятор, чтобы он инитил не только ссылки?

Да не должно быть трудно. Не знаю, почему Ominc решили этого не делать...

Это какие такие нормальные ЯВУ? Java и C# что ли? Так там нулями забивают, а это жуткая потеря производительности.
Вот смотрите: 6.119 секунд супротив 35.932 секунды:

Опять подтасовываем результаты? Здесь меряется скорость "GC vs стэк". Кстати, в такой постановке у шарпа очень приличный результат.

> static void Do (ref Data a, int level)
> {
> Data b = new Data();
> ...

А не корректней ли тут делать просто "Data b;" вместо "Data b = new Data()"?

Кстати, хотелось бы узнать хоть один осмысленный пример существования такой структуры с мусором внутри. В обероне нельзя создавать и возвращать из функций структуры (только передавать по ссылке и инитить)?

Ну что Вы, ни в коем случае. Сравнение честное. В языке C#, struct - является value-типом. А следующий синтаксис объявления и инициализации:

похож на синтаксис объявления и создания reference-типа для "однообразия" - так решили разработчики языка. Таким образом, в данном случае new Data() - это не создание объекта типа Data в динамической памяти, а размещение соответствующего количества нулей в переменной b находящейся на стеке. Просто синтаксис такой.


Не понимаю о каком ещё мусоре Вы говорите.


Да, в оберонах процедура-функция может возвращать только переменные базовых типов (в т.ч. указатели). Ввод и вывод переменных комплексных типов данных делается посредством VAR, IN, OUT ссылок.


Это невозможно. Ведь переменная b не только объявляется, но и используется. А перед использованием, переменная b должна быть проинициализирована - таково требование языка C#. Если написать так как предлагаете Вы, то программа не скомпилируется.

OK, возражение принимается.



Непроиниченные мемберы.



А в шарпе?



В таком случае это прореха в дизайне языка, которую пытаются решить еще одной прорехой. Если бы язык позволял возвращать структуры, то непроиниченные структуры не имели бы смысла (а, следовательно, в случае правильного использования не было бы никакого реального perfomance fault).

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

Забивание нулями - действительно не лучший вариант. Однако сделать на уровне компилятора отлов хотя бы самых явных обращений к переменным до присваивания им значения было бы можно и нужно.

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



Как в дельфе не знаю, но в нормальных компиляторах С++ никаких лишних копирований не происходит. Так что это именно прореха, причем с банальным объяснением: "все в жертву простоте компилятора" (и это в 21 веке).

А куда же их, пардон, девают?
Есть инструкция return, которая убирает из стека входные параметры и копирует туда структуру. Есть инструкция присваивания в вызывающем коде, которая копирует возвращенное значение из стека в переменную. Таким образом, за лишнее удобство платим накладными расходами. А поскольку удобство мы все любим, то платим постоянно. Чего стоят одни строковые операции типа Copy из стандартной библиотеки Дельфе, которые возвращают строку по копированию... Был пример, когда заменой стандартных процедур на процедуры, написанные в стиле Оберона, удалось увеличить производительность программы в 5 раз...
Конечно, в С++ за счет перегрузки операций можно обеспечить и удобство, и быстроту. Ну так это уже другой разговор...

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



Пример я и сам могу придумать. А для практики давно есть профайлеры.