Может. Но что это даёт? Ведь в канонических паскалях файлы классов не существуют.
Да. Но Вы же не классы туда будете помещать, а объекты, т.е. конкретные экземпляры классов. Я не знаю, как это называть, ну назовите какими-нибудь “обобщенными файлами”. )))
Поступите, как тот математик, который ввел термин “мартингал”, а когда его спросили, что это, он нарисовал лошадиный хомут и сказал: вот это - мартингал. А также мартингал то, о чем я говорил ранее."
Да, но это не экземпляры структур. Экземпляры структур и классов - две абсолютно разные вещи хотя бы потому, что структуры имеют строго фиксированный размер, а классы - нет. Я и говорю, что файл с экземпляром класса нужно не file of обозначать, а как-то иначе.
Файл обозначать не файлом? Вы там что курите? ))))
Вам полный список 
Просто если обозначать это стандартным образом, то опять пойдут недовольства по поводу каверкания каконов.
нарезать, создать последовательность, такой бред… а если у меня счетчик Int64 или Biginteger или динамический и шаг тоже динамический… безусловно создание последовательности это интересная штука, НО для использования в счетчике цикла это уж совсем тундра, давайте уж тогда комбинации генерить, че мелочится или слабо???- создал массив закинул сочетания и вытягиваешь, а цикл назовем ForComb(krz,dk); где krz = количество разных значений, dk =длинна комбинации…))))))))) Смотрел, код PascalABC написанный на С# и спотыкался на циклах For… Нахрена спрашивается писать новую среду если она не расширяет возможности, а урезает, и извращает ассоциативный ряд??? К стати может кто подскажет как подать разработчикам некий модуль, ХОЧУ ПОМОЧЬ ПРОЕКТУ! (чтоб такие вещи были внутри компилятора, а не самому его постоянно подставлять, меняешь систему и понеслось… задолбало), Короче, конвертер чисел, из любого исчисления в любое другое, чтоб они его включили в дистрибутив, а то как то хотел вывести значение в 16 речном исчислении и в итоге понял, совместимости с делфи практически нет. У меня есть хороший маленький модуль, с функциями RToInt(R:из какой речьности integer, S:число string):Integer; и IntToR(I:число integer, R:в какую речьность integer):string; а также для длинной арифметике Biginteger RToBig(R:cardinal, S:string):Biginteger; и BigToR(Bi:Bigtointeger;R:cardinal):string; но если нужно перегружу, чтоб было всего две к примеру RToInt и IntToR, код мой, работает просто, конвертит любую речность в 10 речную, затем из 10 речной в любую другую. Захотите подправите, а можете так влупить, работает хорошо, использую постоянно так как занимаюсь комбинаторикой.
В первую очередь, покажите свой проект в Болталке. Там хотели удалить дизайнер форм, прикрываясь тем, что он никому не нужен и плохо работает.
На будущее, не стоит за другими повторять пример неуместного поведения на форуме - использование чрезмерного количества сленга.
Никогда впредь так не делайте. Для того, чтобы зацеплять есть другие способы.
2 лайка
в PascalABC функции с одинаковыми входными параметрами НО с разными выходными НЕ_ПЕРЕГРУЖАЮТСЯ. Ругается на повторное объявление. Что делать??? вариант с изменением типа не_подходит, исправляйте ошибку, а не учите этике, у меня бы красный диплом был, еслиб все оценки были как по ней…)))
Function tvoyumat(R:integer):integer;
begin
result:=R+1;
end;
Function tvoyumat(R:integer):string;
begin
result:=R.ToString+‘1’;
end;
Перегрузка подпрограмм, которые отличаются лишь выходными параметрами невозможна. Требуется хотя-бы одно отличие во входных параметрах.
1 лайк
Последние пару месяцев я занимаюсь тем, что никто, как я думаю, еще пока не сделал - пытаюсь написать книгу, в которой будет описание РаsсаlАВС.NЕТ, пусть поверхностное, но все же достаточно полное, а также руководство для начинающих по этой системе программирования.
Попытка описать язык, пока что частичная - я не дошел и до середины - позволила уже сейчас взглянуть на РаsсаlАВС.NЕТ в целом и понять, насколько он стал “раздутым” в сравнении с другими языками. Оставив в основе “унаследованный от предков” Паскаль, неся в себе груз частичной совместимости с Delphi и Free Pascal, прихватив “все лучшее” из Python, Haskell, C# и т.д, щедро сдобренный синтаксическим сахаром, язык стал просто огромен. Да, писать на нем быстро и комфортно, каждый может взять из него некоторое подмножество и работать с ним. Получилось как бы много языков в одном.
Причем, продолжает получаться. У языка нет жесткой спецификации и это делает проблематичной попытку его даже просто описать. Сегодня в языке чего-то нет, а завтра оно оно уже есть. Бывает и наоборот, вот оно было - и нет. Это неплохо, что язык совершенствуется, я повторюсь: это делает затруднительным его описание. Иногда мне кажется, что разработчики уже сами начали прогибаться под объемом языка. А чем иначе объяснить ситуацию, когда одно и то же делается двумя или даже тремя разными способами? Когда одно и то же дают вызов статического метода класса, функция и расширение? Я могу понять, что это просто так получилось, но это же утраивает описание! Не всегда получается написать об этих, таких разных средствах в одном месте пособия для начинающих.
В языке есть конструкции, которые я пока что даже объяснить не могу. Возможно, они пришли из каких-то глубин С++/С# (более того, продолжают приходить, если их вовремя не отфутболивают разработчики). Тем более, я не могу объяснить потенциальному читателю, зачем нужны эти конструкции, почему он должен тратить время на знакомство с ними и их осмысление. Ощущение, что введено “на всякий случай, а вдруг кому-то понадобится?”.
К чему я это все пишу? К тому, что у меня предложение есть такое. Пусть каждый, кто предлагает что-то добавить или удалить из языка, свое предложение будет сопровождать внятными ответами на следующие вопросы:
- что это новшество даст?
- насколько оно будет востребовано целевой аудиторией?
- какие изменения это потребует сделать в синтаксисе языка (что еще оно затронет?)
- насколько хуже писать программу сейчас, без предлагаемого новшества?
- привести пример программы.
P.S. А если коротко, Хотите оценить язык - попробуйте сделать его описание.
1 лайк
Сама идея написать книгу по языку - мне нравится. Но, хотелось бы заметить, что есть трудные для описания места языка, к примеру, автовывод типов. Пока мы от @Admin не добьемся чётких правил по поводу когда явно указывать тип, а когда нет, не думаю, что стоит что-то в этом плане утверждать. Разработчик лучше знает что и как в языке. Остается лишь это узнать нам.
Не исключаю, что займусь разработкой своего Паскаля.
А, где указывать тип - это проще. Для переменных с автовыводом типов если это лямбда с неявными типами, то обязательно. и если nil то обязательно. В остальных случаях автовыводится.
упомянающие->упоминающие
Я думал это у меня с грамматикой плохо не_программерских языков плохо))) Ну за вас же компьютер может исправить.
А можете сразу ссылки в каждом пункте делать. К примеру в первом пункте превратить “целый раздел” в ссылку на него. Так будет удобнее.
Он и исправил. Спасибо за замечание.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021