Можете, а хотите? Ну или будете? А если да, то разработчики Вас встретят с распростертыми объятиями. Тогда в чем вопрос? Вперед!
У меня тоже есть личный опыт. Хороший, ибо иначе не могло быть - за это деньги платили))) Мы по договору перерабатывали практически все прикладное программное обеспечение НПО “Магнит” (г. Новочеркасск") с языка Кобол на PL/1 с учетом изменения некоторых спецификаций. АСУ целого завода! И ничего, за 8 месяцев справились группой из двух человек.
Вообщем, я библиотеку Вашу приму. Может, что попрошу скорректировать. Просто это большой труд.
И тогда - была разница. За деньги и по спецификации.
Собственно, все шло к тому, чтобы выяснить, как проще: одна мегабиблиотека в стиле uses StudLib или множественное uses Fraction; uses Matrix; uses Polinomial; uses МногоЕщеЧто;
begin
// создали матрицу
var a:=new integer[3,3] ((1,2,3), (4,5,6), (7,8,9));
// что-то с ней сделали
a.Println(2);
// а теперь надо вместо нее заполнить матрицу 2х4
Writeln;
a:=MatrGen(2,4,(i,j)->Arr(1,2,3,4,5,6,7,8)[4*i+j]);
a.Println(2);
end.
Есть ли какой-нибудь более элегантный способ переопределить и переинициализировать массив? Если нет, то быть может, нужно сделать Matr() по образу и подобию Arr() ?
А нельзя снова new integer?
Может и можно, но это как-то некрасиво, если нужно делать много раз. Например, в программе тестирования, когда многократно требуются наборы массивов с разными размерами и содержимым. Я помню, конечно, про автоматическую сборку мусора, но хорошо ли так активно его плодить?
Т.е. если Вы, как Разработчик, поощряете подобный стиль программирования, буду его использовать:
begin
var a:=new integer[3,3] ((1,2,3), (4,5,6), (7,8,9));
a.Println(2); Writeln;
a:=new integer[2,4] ((1,2,3,4),(5,6,7,8));
a.Println(2); Writeln;
a:=new integer[3,2] ((1,2),(3,4),(5,6));
a.Println(2)
end.
А с другой стороны, ведь когда пишется что-то типа [quote=“RAlex, post:253, topic:143”] a:=MatrGen(2,4,(i,j)->Arr(1,2,3,4,5,6,7,8)[4*i+j]); [/quote]
все равно фактически происходит то же самое: создается новый массив и старая ссылка на прежний массив утрачивается, попадая в объятия к сборщику мусора.
Да, именно так. Я рекомендую инициализировать повторно. Активная сборка мусора - это нормально
Всё дело в том, кто ставит систему на ПК, любой нормальный системщик никогда не поставит чистую Винду, он всегда отключит всё гавно из неё и поставит нормальный софт с драйверами.
При создании возвращающей массив функции, при условии, что все манипуляции с результатом проводились с использованием других процедур, компилятором выводится предупреждение, что якобы возвращаемое значение не определено. Если я все правильно понял, то этот недочет нужно исправить.
Появилось очередное изменение, посмотрел на GitHub, думал, что-то интересное, а вышло что забавное: @ibond сделал “украинскую локализацию”. Видимо из-за запрета на Украине русского языка)) Надо ли ждать в дальнейшем казах тили, беларускую мову, а также, несомненно, катакану?
Мы пока думаем, надо ли оставлять украинскую локализацию в инсталляте или сделать внешний пак и разместить на сайте. А то как-то странно выглядит: украинский, русский и английский. Если бы было много, тогда понятно.
А история украинской локализации проста. Её сделал один украинский преподаватель и прислал нам. http://computer-science.in.ua/2017/07/16/ukrajinizacija-pascalabc-net/
Ещё в разные времена мне предлагали сделать локализацию на немецком и казахском, но к сожалению, кроме намерений я ничего не получил.
Так это только инсталлятор… я-то подумал, что локализация полной будет. Подсказки, сообщения об ошибках…
Исправим.
Вы пользуйтесь вместо Split методом s.ToWords
Там полная локализация. Инсталлятор как раз не локализован. Да и зачем его локализовывать
или сделать внешний пак и разместить на сайте.
зачем? она уже добавлена.
если в папке оставить от модуля только psu файл то компилятор принимает всё написанное но анализатор кода перестаёт подсказывать при вводе, возможно стоит исправить
Как насчёт того чтоб сделать несколько идентификаторов по умолчанию для {$ifdef} и {$ifndef}?
(ну и у меня ещё not и and используются в {$ifdef }, в последнем примере, которые сложно адекватно заменить)
Например:
{$ifndef EnvironmentLaunched}
System.Console.Clear;
{$endif}
чтоб в exe файл записывало эту строчку если программа не была запущена через простое F9.
Возьмём пример из CRT:
function RedirectIOUnitUsed: boolean;
var
t: &Type;
begin
t := System.Reflection.Assembly.GetExecutingAssembly.GetType('__RedirectIOMode.__RedirectIOMode');
Result := t <> nil;
end;
и далее
if (not RedirectIOUnitUsed) {and IsConsoleApplication} then
//здесь ошибка, IsConsoleApplication у нас никогда не инициализируется
//это комментарий из самого CRT, ещё 1 причина добавлять идентификаторы, IsConsoleApplication
//может меняться с помощью {$apptype }, а на сколько я понимаю директивы компилятору так устроены
//что переменной передать значение заданное директивой очень неудобно
Это if становится частью готовой программы и проверяет при запуске каждый раз, можно сказать что это не значительно, но я отвечу что это просто не красиво…
Так было бы на много лучше:
procedure __InitModule;
begin
//можно тут и из C++ взять его ! и &&, тогда можно без пробелов написать, а новички всё равно директивы компилятору не будут использовать
{$ifdef not EnvironmentLaunched and IsConsoleApplication}
Console.CursorSize := 15;
BlankString := ' '*(Console.BufferWidth - 1);
{$else}
Console.WriteLine('Программу с подключенным модулем CRT нельзя запускать по F9.');
Console.WriteLine('Запустите программу, используя Shift-F9');
Halt;
{$endif}
end;
Ну и разумеется спектр применения большой, не только делать код более красивым
P.S. Как недавно было сказано в теме “Помощь новичкам” использовать отладку с CRT нельзя как раз из за этого Halt в инициализации. Возможно стоит заменить на такое:
Console.WriteLine('Программу с подключенным модулем CRT нежелательно запускать по F9,');
Console.WriteLine('такие процедуры как clrscr будут вызывать исключение(ошибку времени выполнения).');
Console.WriteLine('Нажмите Enter чтобы продолжить или завершите программу и запустите с Shift+F9');
Readln;
P.P.S.
Не нашёл замены #pragma из C#, а ведь довольно полезная директива
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021