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

Программирование очень часто связано с математикой(не обязательно сложной), где новые переменные ВСЕГДА равны 0. Это нормально, естественно для самого разработчика. Непонятно, почему, например, Borland не додумалась автоматически обнулять переменные, а уж C++… Не было бы стольких споров… :smile:

Ну ведь не весь модуль критичен? Там есть хоть пара процедур, которые можно стереть?

Вы ещё скажите что странно что в C++ не проверяются границы массивов))) В C++ разработчик следит за всем, это сложно но даёт возможности оптимизации. Но вот студия, к примеру, не даёт читать не инициализированную переменную, так что проблем с этим быть не должно.

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

Директиву я предлагал, но с ней вот проблема - она будет отключать сразу всё, но такое надо очень ограниченному числу людей.

Это как раз очень хорошо, но сделано некрасиво.

Да, но про оптимизацию разработчики уже ясно сказали, что заниматься этим не могут. Слишком сложно. К тому же, я не предлагаю тупо удалить модуль, я предлагаю просто дать возможность его отключить. Например, разрабатывать программу на Паскале гораздо проще, чем на C#. Начинающие могут сначала написать код на Паскале, проверить его, а затем перевести на C#. Вполне понятно, что использовать при этом что-либо из Паскаля нельзя. Вот Вам и пример. А главная фича паскаля-его понятный и лаконичный синтаксис, так было с самого его создания, и отключать это уж точно никто не захочет! :smile:

Вот тут посмотрел свою программу: NET версия TRAC занимает 70кб, Delphi6/Turbo Delphi Win32 - 120кб, последняя Delphi 10.2.3 - 1Мб, Lazarus Win64 450кб, Lazarus linux64 -1.5Мб. Честно говоря, когда я увидел, какая маленькая NET, было даже обидно, столько сил положено. Вы что, ещё меньше хотите?

1 лайк

Вот как раз из математики и пришли 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++ надо писать отдельные подпрограммы, которые должны работать быстро.