Если сто программ переписать - да. Если пару десятков и переработать под удобный интерфейс - why not?
Можете, а хотите? Ну или будете? А если да, то разработчики Вас встретят с распростертыми объятиями. Тогда в чем вопрос? Вперед!
У меня тоже есть личный опыт. Хороший, ибо иначе не могло быть - за это деньги платили))) Мы по договору перерабатывали практически все прикладное программное обеспечение НПО “Магнит” (г. Новочеркасск") с языка Кобол на 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 файл то компилятор принимает всё написанное но анализатор кода перестаёт подсказывать при вводе, возможно стоит исправить
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021