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


#567

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


#568

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


#569

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


#570

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

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


#571

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


#572

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


#573

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


#574

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


#575

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


#576

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


#577

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

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

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

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

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

#578

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


#579

Тут, я так понимаю, Вы имеете ввиду проверку индексов массива. Но ведь она не обязательна! Мы ведь привыкли работать с массивами по индексам в квадратных скобках, передавать массивы как объекты. Проверка осуществляется как раз при работе по стандартной индексации. А теперь вспомним, как с массивами работают в 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[,]). Там обнуления будут абсолютно лишней тратой ресурсов. По-моему, будь обнуление фичёй именно конкретного языка, а не платформы, можно было бы сделать директиву, управляющую автообнулением. Но всё же затраты не очень большие.


#580

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


#581

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

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;


#582

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


#583

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


#584

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

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

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


#585

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


#586

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