>в компилируемых же языках такого механизма в принципе нет

это в корне неверное утверждение.
замыкания есть почти во всех "свежих"

Конечно неверное.

Утверждение не моё, но ketmar, наверное, прочтёт этот твой комментарий.

Возможно, в ближайшие годы во FreePascal могут появиться "замыкания".

(Reply to this) (Parent) (Thread)

>но ketmar, наверное, прочтёт этот твой комментарий.
таки пропустил. %-)

http://lj.rossia.org/users/phantom/33098.html?thread=377418#t377418

>Возможно, в ближайшие годы во FreePascal могут появиться «замыкания».
это вряд ли. скорее таки нечто вроде «делегатов», которые ублюдочны по самой идее.

(Reply to this) (Parent) (Thread)

скорее таки нечто вроде «делегатов»
Их-то наверняка, ибо они и в "Объектном Паскале", и в Дельфах есть. Как продукт вторичный, ФриПаскаль скорее неохотно поддержит чужую фигню, чем сделает по-своему что-то новое.

Сознаюсь/соглашусь: понятия не имею о планах на "замыкания", но какие-то (пока — внутренние) штуки, как-то связанные с функциональной парадигмой там появляются, так что со стороны реализации в компиляторе к "замыканиям" они приближаются (в основном, правда, это SSA и SSU оптимизации, причём SSU, как я понял, может и не появиться, а SSA как-то используется).

Я "делегатами" не пользовался, а вот по (не до конца понятным мне образом увязываемым с "делегатами" как сугубо объектно-ориентированная альтернатива) внутренним классам весьма скучаю.

(Reply to this) (Parent) (Thread)

>Их-то наверняка, ибо они и в «Объектном Паскале», и в Дельфах есть.
это где же в Delphi делегаты? впрочем, я считаю, что Delphi закончился на 7-й версии, дальше пошло какое-то пиздоблядство, которое ни ставить, ни использовать не надо.

>а вот по (не до конца понятным мне образом увязываемым с «делегатами» как
>сугубо объектно-ориентированная альтернатива) внутренним классам весьма
>скучаю.
лучше бы сделали одну простую вещь — защищённые/приватные объявления в модуле.

interface
type private TMyType;
type protected PMyType = ^TMyType;
implementation
type TMyType = ….;

с обычным смыслом protected/private. и да — возможностью объявлять имя в интерфейсе и описание в реализации. мне часто этого не хватало.

(Reply to this) (Parent) (Thread)

Я пользуюсь D2007. Она более готова к современным реалиям: в D7 неправильно работают объекты (хранящийся в стеке аналог класса), ужасная работа с памятью (медленно и глючно, естественно, в условиях большой нагрузки, которую, видимо, не особо отлаживали/предполагали в давние годы).

Часть этого можно исправить какими-то заплатками неофициальными, но поддержка всякой "Просеки" и т.п. даётся с ещё бОльшим трудом (для меня лично камень преткновения — управление памятью).

Мне не нравится среда разработки, но всё равно пользуюсь.

Вот так.

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

(Reply to this) (Parent) (Thread)

>в D7 неправильно работают объекты (хранящийся в стеке аналог класса)
??? O_O это, пардон, бредятина какая-то написана. class — это одно. object — совсем другое. class instance — третье. object instance — четвёртое. ниего не понял.

>жасная работа с памятью (медленно и глючно, естественно, в условиях
>большой нагрузки, которую, видимо, не особо отлаживали/предполагали в
>давние годы).
все давно привинтили fastmem заместо стандартного аллокатора (который дебильный, да). в следующих версиях даже борланды догадались и запихали fastmem в коробку. мне это удивительно, потому что обычно они пихают в коробку наиболее глючный и наименее юзабельный из всех возможных вариантов (FastNet, QuickReport, Rave Reports, Indy).

>Мне не нравится среда разработки
аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-) впрочем, формы в Delphi ублюдские — где layout manager? завсегда приходилось накладывать поверх свои костыли.

>Лазарь для графических интерфейсов не годится совершенно.
O_O пуркуа? у меня отлично получалось, чем именно он не годится?

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

(Reply to this) (Parent) (Thread)

??? O_O это, пардон, бредятина какая-то написана
ЧЁД: http://community.freepascal.org:10000/docs-html/ref/refch6.html#x61-690006 (у объектов ключевое слово "object", а не "class")

все давно привинтили fastmem заместо стандартного аллокатора
В принципе да, но неофициально.

аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-)
Близко к этому и у меня. Хотя в седьмой версии интерфейс и быстродействие получше обычно.

где layout manager?
Что это?

чем именно он не годится?
Свойств мало у каких-то стандартных классов, поддержка Дельф хромает (если бы какое-то время назад не было проблем с какими-то примитивными вещами, чуть ли не с полужирным шрифтом, то меня не волновала бы совместимость с Дельфами). Я опять посмотрю, наверное, скачаю, скажу. Правда, я собирался дождаться версии 1.0.

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

(Reply to this) (Parent) (Thread)

>у объектов ключевое слово «object», а не "class"
я в курсе, я ещё помню торжественное появление TP5.5. потому и озадачиваюсь — не бывает «хранящихся на стеке объектов», только экземпляры оных. и, кстати, что там работает неверно? по-моему, всё точно как в TP5.5.

>В принципе да, но неофициально.
с D8 или D10 официально.

>Что это?
в двух словах — «автораскладчик» контролов. который криво-криво и тупо-тупо, кряхтя и матерясь, можно сэмулировать кучей панелей и выставлением align: layout managers. нужен для нормального создания «резиновых» морд. align/anchors тут не катит, слишком бедный инструмент.

>войств мало у каких-то стандартных классов, поддержка Дельф хромает
Lazarus is *not* an 'open source Delphi clone'. So don't expect 100% compatibility.

>Яве, например, сборщик мусора не помогает (тормоза)
а это уже другая проблема. см. Oberon — и мусор собирает, и тормозов нет. и дальше BlackBox Component Builder, как очень навороченая RAD с инсталлятором в 5 мб, написаная на Component Pascal — наследнике Oberon.

(Reply to this) (Parent) (Thread)

и, кстати, что там работает неверно?
Исходники не пришлю, но изначально написанное на ФриПаскале в D7 вызывало глюк в компиляторе, в D2007 нормально компилировалось (даже если глюк в программе, в компиляторе он точно есть). Замена объектов на классы проблему решала. Но везде переделывать не хотелось.

с D8 или D10
Это определённо не D7…

layout managers
Да, вещь нужная. Да, её нет.

So don't expect 100% compatibility.
Как я и написал, после выбора Дельф для перехода на Лазаря эта поддержка необходима. Дельфы были выбраны два года назад, тогда Лазарь хромал (кажется, я даже полужирным шрифтом без извращений не мог на форме писать).

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

(Reply to this) (Parent) (Thread)

>Замена объектов на классы проблему решала.
хм. объекты и классы — сильно разные вещи. подозреваю, что ошибка таки была в логике.

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

>Это определённо не D7…
а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».

>после выбора Дельф для перехода на Лазаря эта поддержка необходима
да, придётся поработать напильником. зато один раз. %-)

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

>Сейчас в процессе рассмотрения вакансии цепепешной
искренне сочуствую. злейшему врагу не пожелаю работать в цпп-проекте. плавали, знаем…

(Reply to this) (Parent) (Thread)

подозреваю, что ошибка таки была в логике.
1. Во ФриПаскале работало без намёков на проблемы.
2. Никакие ошибки в логике пользовательской программы не должны вызывать исключений в dll-ках компилятора.

а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».
Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не у меня на машине. Вот переход на D2007 — понятно. А что-то курочить, когда у большинства и так работает — не поймут. И так с надстройками (TMSUnicode, ещё что-то) накладки происходят иногда.

да, придётся поработать напильником. зато один раз. %-)
Ненавижу ковыряться с собственным старым кодом. Я ж не так давно профессионально стал программировать, и тексты у меня весьма корявые.

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

(Reply to this) (Parent) (Thread)

>1. Во ФриПаскале работало без намёков на проблемы.
это ещё не значит, что всё было правильно.

>2. Никакие ошибки в логике пользовательской программы не должны
>вызывать исключений в dll-ках компилятора.
мнэ… а зачем ты с собой эти DLL таскал и использовал? оно лицензией запрещено.

>Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не
>у меня на машине.
ну и что? положил к себе в каталог, добавил в bpg — получилось. чем оно отличается от исходников, написаных лично тобой в этом случае? это не компоненты, это модуль, прописал в uses и поехало.

>Ненавижу ковыряться с собственным старым кодом.
хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)

>Ява меня пугает больше
как раз жабка проще в плане синтаксиса. для цпп вообще компилятора не существует (вроде бы всё ещё нет; обломки, не реализующие стандарт ANSI, полноценными компиляторами называть нельзя), о чём дальше говорить-то?

а библиотек и там, и там немеряно, запутаешься одинаково.

(Reply to this) (Parent) (Thread)

мнэ… а зачем ты с собой эти DLL таскал и использовал?
Ой! А я просто кнопочку "компилировать" в среде разработки нажимаю, а мне пишут об исключении в DCC70.DLL. Это запрещено лицензией??

это не компоненты, это модуль, прописал в uses и поехало.
В тот момент оказалось, что в D2007 работает, а в D7 — нет. То, что дело именно в управлении памятью, скорее догадка.
О том, что реальные пацаны меняют управление памятью, я узнал существенно позже (переделывать проекты D2007 в D7 наверняка можно, но лень).

хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)
Но что-то тоска берёт.

запутаешься одинаково
По-разному. К Яве-то у меня неприязнь. Её ещё преодолеть надо.

(Reply to this) (Parent) (Thread)

>А я просто кнопочку «компилировать» в среде разработки нажимаю
не нажимай. IDE — то ещё глючище, особенно если у тебя компонентов понаставлено. собирай при помощи dcc32.exe

>переделывать проекты D2007 в D7 наверняка можно, но лень
не надо там ничего переделывать. включил в проект fastmem, прописал во всех uses первым и всё. это все изменения.

>К Яве-то у меня неприязнь.
у меня тоже, хрен редьки не слаще, в общем-то.

(Reply to this) (Parent) (Thread)

не нажимай. IDE — то ещё глючище,
Что ж, хороший повод для обновления (правда, среда D2007 глючит в целом больше, но со сборкой проблем меньше).
Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно отличаются в этом смысле.

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

(Reply to this) (Parent) (Thread)

>Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно
>отличаются в этом смысле.
ещё как. среда падучая по жизни, и по абсолютно любой непредсказуемой причине. очень много к этому добавляют всякоразные компоненты, которые срут куда не попадя в памяти. вообще, категорически воспрещено юзать что-либо сверх Raize (и иногда TNT). а лучше и без них. и сервиспаки все накатить, натурально.

а в следущих версиях исправили как раз стабильность: падать стало стабильно чаще. %-)

(Reply to this) (Parent)

защищённые/приватные объявления в модуле.
Зачем?

(Reply to this) (Parent) (Thread)

interface

type private TMyOpaque;
type PMyOpaque = ^TMyOpaque;

type TMyOuterClass = class
 protected
  fData: PMyOpaque;
 ….
end;

implementation

type TMyOpaque = record
  …
end;

что даёт рабочую проверку типов, но невозможность «поковыряться» в TMyOpaque.

без такой фигни придётся переносить TMyOpaque в реализацию, делать fData простым указателем и потом без конца трахаться с приведениями. или показывать всем потроха TMyOpaque.

плюс — поскольку TMyOpaque приватная, класс-наследник из другого модуля может юзать указатель TMyOpaque/PMyOpaque, но всё равно внутрь никак не влезет.

модификатор protected нужен для расширяемых записей (вроде в D8 или D9 это появилось).

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

ну, когда ты один код пишешь — вполне пофигу. а вот когда рядом пара обезьянок — лучше от них попрятать всё, что можно. если не спрятать — всенепременно полезут кривыми руками куда не положено.

(Reply to this) (Parent)