freepascal.ru

zub писал(а):хде?

Откуда мне знать? Где-то там, нужно штудировать код и выявлять, где создаются авто-инициализируемые массивы, по типу, как у ТС. А таких, массивов, в любом модуле много.

beria писал(а):Тем более, вот тут я согласен, что вообще её код крайне не рационален, чем вообще грешат многие фрипасовские стандартные либы... А про С тут скорее потому что сишные либы более тщательно отлаживались многими годами и их просто тупо очень много на любой вкус и цвет, так что громадный выбор, тем более что в С комьюнити принято делится исходниками, чего в клонах паскаля не наблюдалось и не наблюдается, так каждый сам за себя....

Просто паскалистов - меньше по количеству, т.к. общепринятое мнение что С++ чем-то там круче. Но моё мнение, что на самом деле паскаль удобнее, просто нужно допилить парсер, чтобы итоговый asm код из паскаля, был идентичен сишному. Если кто-то скажет что это невозможно, то это будет лажей, т.к. asm - одинаковый.

Лекс Айрин писал(а): а от жизни нелегкой.

А чтобы жизнь была простой и легкой - в идеальном случае я всегда довожу код чтобы вообще не было никаких сообщений от компилятора. И это правильно. И это по уму. И сколько раз я ловил код когда неявные преобразование типов могли убить содержимое строк, но спасибо компилятору, который это отслеживает...

зы: а давайте запретим все ссылочные переменные как в ранних бейсиках ибо вообще не менее 80-90% ошибок в любой программе может быть только от них..... Зато как круто повысится надежность программ....

Добавлено спустя 4 минуты 18 секунд:

vitaly_l писал(а): паскаль удобнее,

Паскаль не только удобнее, а он удобнее в разы, хотя потому что опирается на человеческую алгоритмическую логику, в отличии от полного изврата сpp, логика работы и неоднозначности синтаксиса которого часто не понятна даже автору. Сразу в таком случае вспоминаю инициализацию UNO от Опен оффиса.... гы-гы-гы. Но блин, когда в фрипасе будут работать инлайн-процедуры и можно будет отказать от обязательного ручного инициализирования объектов. Кстати в последнем случае и количество ошибок сократится....

vitaly_l
>>Откуда мне знать? Где-то там, нужно штудировать код и выявлять
зачем тогда форум пачкать? ищи, найдешь пиши.

beria писал(а):в идеальном случае я всегда довожу код чтобы вообще не было никаких сообщений от компилятора. И это правильно.

Тогда не надо ныть, что он тебя лишний раз предупреждает.

beria писал(а):а давайте запретим все ссылочные переменные как в ранних бейсиках ибо вообще не менее 80-90% ошибок в любой программе может быть только от них..... Зато как круто повысится надежность программ....

К сожалению, не поможет. В бейсике был прямой доступ к памяти, по крайней мере, в некоторых реинкарнациях, поэтому ссылочный тип там был... неявный. Да и надежность не повысится, а понизится, так как придется писать больше кода. В ТР он тоже, кстати, был то ли в 6 то ли в 7 версии.

Лекс Айрин писал(а):огда не надо ныть, что он тебя лишний раз предупреждает.

Вы меня с кем-то путаете. Как раз к парсеру у меня нет вопросов, тем более оптимизатор кода там постоянно докручивают. Иногда возникают вопросы к самой логике реализации и чуть чаще к кривости стандартных либ...

Лекс Айрин писал(а):В ТР он тоже, кстати, был то ли в 6 то ли в 7 версии.

Уже в ТPЗ, которому за глаза, включая среду программирования, хватало 256 кб оперативной памяти уже был и прямой доступ к памяти через mem[xxx], и абсолютные переменные, и полный набор new, getmem, dispose, freemem. и прямой вызов прерываний из программы через тип register и возможность включения бинарных инлайн процедур (в фрипасе этого до сих пор нет) и удобнейший оверлейный модуль, коего мне не хватает и сейчас ... и вообще много чего... Хотя и недочетов было много.

beria писал(а):и удобнейший оверлейный модуль, коего мне не хватает и сейчас ...

его убрали, насколько я знаю, из-за отсутствия необходимости. Оверлеи возникли из-за недостатка памяти. А в винде/никсах просто нет прямого доступа к памяти, если, конечно, нет желания словить исключение.

beria писал(а):Вы меня с кем-то путаете.

Возможно.

beria писал(а):Иногда возникают вопросы к самой логике реализации

Тут, ксожалению, совет только один -- форкнуть и переделать самому, благо исходники есть(((

Лекс Айрин писал(а):его убрали, насколько я знаю, из-за отсутствия необходимости

Угу. Знаю. Только вот подобная экстенсификационная логика, когда всем наплевать сколько ресурсов будут кушать даже элементарные операции, а дыры затыкались не реализацией и аглоритмами, а новыми гигабайтами адресного пространства и гигагерцами процессоров - мне никогда не нравилась.... Апофигей этого обычная файловая качалка, которая заняла на диске более 300 мегабайт и скушала почти гиг памяти в фоновом режиме

Лекс Айрин писал(а):форкнуть и переделать самому, благо исходники есть(((

Вот-вот. Чем и занимаюсь вместо более важных вещей ...

beria писал(а):Только вот подобная экстенсификационная логика, когда всем наплевать сколько ресурсов будут кушать даже элементарные операции

Вообще-то это задача ОС, а не самой программы. К тому же, это немного разные понятия. Программа может, например, раздуться из-за включенных в нее ресурсов и рунтайм библиотек. (которые можно как бы и вынести из тела программы, но сие не всегда и всем удобно). Есть еще причины, но они уже рассматривались на форуме и вроде как признано нерентабельным более тщательное удаление мертвого кода.

beria писал(а):а дыры затыкались не реализацией и аглоритмами, а новыми гигабайтами адресного пространства и гигагерцами процессоров - мне никогда не нравилась....

А кому понравится? К сожалению, экстенсивный путь развития всегда сложнее. (у тебя, кстати, в тексте небольшая ошибка... видимо речь идет об интенсивном пути, когда захватываются новые "территории").

beria писал(а):Апофигей этого обычная файловая качалка, которая заняла на диске более 300 мегабайт и скушала почти гиг памяти в фоновом режиме

никогда не пользовался. Хватало встроенной в браузер. Ну или ftp доступа.

Лекс Айрин писал(а):Программа может, например, раздуться из-за включенных в нее ресурсов и рунтайм библиотек.

Тут главный критерии - правильный выбор как среды и библиотек и включение только нужного, а не как в в иных старых реализациях паскаля - вообще всего что можно и вне зависимости надо это физически надо или не надо.... Вот к примеру пример плохого подхода, с которым сам сталкивался и работал - сравнение современных жавовских систем проверки орфографии и древнего орфографического корректора от 95 и 97 МS оффисов, кстати исторически отечественный продукт, которые прекраснейшим образом без нагрузки системы и без проблем работали на младших пентиумах и 16 мб RAM. И по качеству и по скорости они ,увы, делают вчистую жавовские приложения несмотря на гигабайты оперативки и многоядерные процессоры.... Да.... и еще сотню гигов дырявой и вечно недоделанной жавы надо поставить..

Лекс Айрин писал(а):у тебя, кстати, в тексте небольшая ошибка

Гм.... Неужто глючу... Смотрим вики
Экстенсификация (лат. extensivus расширяющийся, удлиняющийся) — процесс и организация развития производства, в котором увеличение производительности достигается за счёт количественного увеличения производственных мощностей. То есть, большее количество рабочей силы и техники.. (с) https://ru.wikipedia.org/wiki/%D0%AD%D0 ... 0%B8%D1%8F

Лекс Айрин писал(а):Хватало встроенной в браузер. Ну или ftp доступа.

Аналогично.. Я вообще сторонник минимализма , консольных файловых менеджеров, и крайней узкой специализации программ. Не потому что антиэстет, а просто так быстрее работается при часто большем функционале. Но хочется посмотреть на майнстрим с рюшечками и кружавчиками

beria писал(а):Гм.... Неужто глючу... Смотрим вики

мда... глючу я(((

beria писал(а):Тут главный критерии - правильный выбор как среды и библиотек

того, что мне нравится, к сожалению, нет. И похоже, не предвидится((

связка fpc+Lazarus на данном этапе выбор лучшего из худшего... в этом случае, плохо быть программистом и фантастом. Предполагается, что IDE по мощности примерно равно мощности языка... что далеко не так((

beria писал(а): Я вообще сторонник минимализма , консольных файловых менеджеров, и крайней узкой специализации программ. Но хочется посмотреть на майнстрим с рюшечками и кружавчиками

Я не любитель минимализма, но, скрипя сердцем, соглашаюсь, что 98е окна намного удобнее последующих выпусков.
И, кстати, использование консоли сейчас мною суровая необходимость. Мне очень импонирует подход никсов с их связками консольная утилита+ графическая оболочка.

Кстати, zub, спасибо за черепаху. Очень помогает.