Замечания и предложения

Вот как раз из математики и пришли O(n) и O(1) о которых я писал как об аргументе не инициализировать. А новых (и старых) переменных в математике что-то я не видел нигде. Хороший “математический” подход к программированию можно найти где нибудь в AXIOM CAS. А нули для всех типов - это обычное “разгильдяйство” в стиле С.

Ничего плохого в этом нет. Опытный программист все равно будет в своей программе инициализировать все “ручками”, потому что сегодня есть автоматическая инициализация, а завтра ее нет… А для новичка, если он где-то пропустил даже инициализацию - ну вот такой костыль. Главное - чтобы преподаватель постоянно обращал внимание на то, что такой стиль не панацея и есть системы, где “номер не пройдет”.

Так я не про язык для обучения. Тут всё правильно. Но, если я правильно понял, глядя на спецификации NET, они подрезали целый класс методов оптимизации скорости. Вот если я активно работаю с чем то типа shortstring, там достаточно первый байт нулём забить. Зачем забивать всё остальное нулями?

1 лайк

Вы хотите, чтобы я за Майкрософт Вам ответил? Я Вам напомню старенький анекдот;

Президент Apple умер и попал в рай. На небесах его встречает апостол Петр:

  • Добро пожаловать!
  • Спасибо, но здесь не будет Билла Гейтса?
  • Нет, что вы, после DOS и Windows в рай не берут.

Вдруг из-за спины апостола появляется Билл Гейтс. Глава Apple - в шоке, а апостол его успакаивает:

  • Нe беспокойтесь, это Бог, просто он думает, что он - Билл Гейтс.

Это был риторический вопрос. А Билл тут вовсе не причём - википедию посмотрите - в день официального объявления net он передал пост главы компании Балмеру. А разработкой C# вообще руководил создатель Турбо Паскаля Хейлсберг. Жизнь она смешнее всяких анекдотов. А Балмер теперь тоже ушёл и новый глава Майкрософт вот Q# создаёт с очередными последователями Вирта.

Тут, я так понимаю, Вы имеете ввиду проверку индексов массива. Но ведь она не обязательна! Мы ведь привыкли работать с массивами по индексам в квадратных скобках, передавать массивы как объекты. Проверка осуществляется как раз при работе по стандартной индексации. А теперь вспомним, как с массивами работают в C++. Там нет класса Array, да и массива в привычном для нас виде. Длина массива хранится отдельно от него, а доступ ведётся исключительно по указателям на участок памяти. Но ведь так можно сделать в любом .NET-языке, несмотря на то, что платформа не очень это любит. Например, так будет выглядеть код на Паскале, возводящий элементы массива в квадрат:

Uses System;
Type Pointer = ^Void;
Type PInt32 = ^Int32;
Function Sqr(a: array of Int32): array of Int32;
Begin
  Var P:=@a[0];
  For Var i:=0 to a.Length-1 do
  Begin
    P^:=(P^)*(P^);
    P:=Pointer(Int32(P)+4);
  End;
End;

Как мы видим, ничего страшного. Зато никакой проверки нет, работа напрямую с данными. По поводу автоматического обнуления - вопрос и правда спорный. С одной стороны, это удобно. Например с массивами(особенно многомерными), не нужно засорять код обнулениями. С другой - нет. Например, если наш массив заполняется какими-то данными, не зависящими от его изначальных значений(Например, запись данных изображения из Bitmap в Byte[,]). Там обнуления будут абсолютно лишней тратой ресурсов. По-моему, будь обнуление фичёй именно конкретного языка, а не платформы, можно было бы сделать директиву, управляющую автообнулением. Но всё же затраты не очень большие.

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

Не понял, зачем Вы так делаете. Почему нельзя

Uses System;
Procedure Sqr(var a: array of Int32);
Begin
    For var i:=0 to a.Length-1 do a[i] := a[i]*a[i]
End;

Спасибо, я как бы… несколько тоже в теме. Просто не подумал, что есть люди, которые понимают все только впрямую и анекдоты им противопоказаны.

Да, лучше прямо говорить, так как я действительно не уверен, что понял суть иносказания. Я отвечал исходя из того, что подразумевалось, мол ничего не поделаешь.

Так, безусловно, можно, но говорить после этого о том, насколько плохая платформа .NET не нужно! :wink: При обращении к элементу массива через индексатор, происходит проверка его(индексатора) на вхождение в границы. Конечно, это гораздо удобнее. Именно так и надо делать на этапе разработки и отладки, однако в готовом продукте это не есть хорошо. Вы попробуйте создать массив из пары миллионов элементов, сравните скорость работы с данными по указателям и по индексатору. Думаю, это вас убедит. А ведь есть и дву- и трёх- мерные массивы… Вообще говоря, .NET предназначена для упрощения разработки приложений и систематизации методов операционной системы и часто встречающихся при разработке приложений типов. Платформа даёт сахар, а разработчик должен довести его до приличного состояния. В общем,

Плохому танцору...

ну, в общем, понятно. :smile:

На всякий случай повторю. Я вообще ничего не говорил о контроле границ. В обычном Паскале это отключается директивой. Разве здесь нельзя? А если об эффективности Вашей программы, то почему Вы думаете что массив хранится в непрерывной области памяти. А если сейчас это так, кто запретит в будущем разработчику компилятора разбить на куски (например по 64kб)?

Массивы эти из .Net, там их вряд ли поменяют… Хотя это всё равно извращенство)) На C++ надо писать отдельные подпрограммы, которые должны работать быстро.

А как safe resize делать?

И пробовал и создавал. И двух миллионов было мало. Вот как раз лежит одна такая программа на Дельфи, там трёхмерный массив и по каждой размерности надо несколько сот, но как только массив больше, чем четыре гигабайта, то как вообще с ним работать, даже если 64 разрядный компилятор и система?

Вспомните определение массива. Если бы каждый элемент был в какой-то случайной части памяти, то программы работали бы на порядок дольше.

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

А вот это уже обидно было!

© Алиса, Яндекс

Что для Вас обычный Паскаль? Турбо? Но ведь это форум PascalABC.NET! В PascalABC.NET этого сделать нельзя(сейчас).

А причём тут Дельфи?

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

А вот тут пожалуйста поподробнее.

Не net имелся в виду. Delphi, Lazarus, Free. Кто о турбо вообще вспоминает?

А Вы, в свою очередь, вспомните архитектуру памяти современного компьютера, схему адресации памяти и расскажите, где Вы видели, чтобы, к примеру, мегабайт памяти аппаратно адресовался впрямую непрерывно? Определение массива, которое Вы привели, - это логическое определение, ничего не говорящее о физической реализации. Оно досталось нам от первых ЭВМ, где память была действительно линейной. А в той же Windows Вы можете гарантировать, что Ваш массив вообще не окажется в виртуальной памяти? То-то и оно!