Вы знакомы с FreeAndNil() , но используете ли вы его? Как часто? Вы используете его правильно? Как и большинство вещей в разработке программного обеспечения, это сложная тема. Итак, давайте посмотрим, что скажут эксперты. Мы собираемся обсудить детали в дружеской беседе с некоторыми из ваших любимых MVP.
- Этот пост в блоге будет включать повтор, слайды и многое другое после вебинара.
Опрос говорит…
Когда вы регистрируетесь для участия в вебинаре , мы предлагаем небольшой опрос, чтобы узнать, как вы относитесь к этому вопросу. Во время вебинара мы сравним общий консенсус с мнением нашей группы экспертов MVP.
Еще больше MVP высказались по этой теме, и у меня есть несколько тизеров того, как они голосовали…
Я пока оставил легенду о том, что диаграммы означают, что вам нужно присоединиться к вебинару, чтобы увидеть подробности, но использование FreeAndNil() довольно равномерно разделено, если мы разделим ответы на общие ответы за и против.
Если мы разберем вещи на детали, то это будет немного более нюансировано. Опять же, без легенды, пока.
Оформление назначенных проверок аналогично, но чуть более выражены отличия.
- В: У меня есть девиз: если ты что-то создал, уничтожь это в конце процедуры! Вот почему я часто использую FreeAndNIl()!
- A: Это не всегда возможно, но я понимаю вашу точку зрения.
- В : Создание экземпляра по запросу часто является разумным шаблоном, и поэтому вам нечего будет помещать в свой указатель!
- А: Хороший момент
- Q: Этот парень занимается программированием?
- A: Да, много. Да, он чрезвычайно опытный кодер и пользуется уважением. Обещаю 🙂
- В : Назовите ваш фиктивный объект «Ноль» 😛
- О: Хорошая мысль.
- В: Я сижу исправленным.
- А: лол
- В : nil — отличный способ подтвердить, что ни на что не ссылаются, и если вы ВСЕГДА освобождаетесь с помощью FreeAndNil, тогда ваш код будет сам поддерживать, что указатель будет нулевым, если он недействителен, в противном случае это всегда допустимый объект.
- A: Он присваивает nil, но бывают случаи, когда вам не нужно присваивать ему nil или когда вы можете скрыть что-то еще.
- В: Как вы можете говорить «всегда используйте интерфейсы», а затем еще и «вы никогда не должны уничтожать то, что не создавали» — совершенно непоследовательно!
- О : Я сказал: «Если можете, используйте интерфейсы», и суть кода в интерфейсе заключается в том, что подсчет ссылок явно предназначен для решения этой проблемы.
- В : Существует множество вариантов использования Assigned и FreeAndNil. Если вы их не используете, то вы либо не используете такие варианты использования, либо вы плохой программист. Говорить, что нет причин когда-либо их использовать, или что если вы их используете, вы не должны этого делать, совершенно неправильно.
- A: Я полагаю, что Ник говорит о том, что использование проверок FreeAndNil и Assigned — это запах кода, который вам может понадобиться для другого дизайна. Кроме того, чрезмерное использование FreeAndNil также скрывает вещи.
- В : Во многих случаях код, ответственный за освобождение объекта, не совпадает с кодом, создавшим объект. Самый очевидный пример — модель управления памятью с подсчетом ссылок.
- А: конечно
- Q: Должен также получить представление разработчика C++
- О: Да, некоторые MVP используют и то, и другое.
- Q: F# использует тип Option (тип объединения с Some и None), чтобы избежать nil, и я считаю, что это требует поддержки в языке (в системе типов). Предоставляет ли Delphi такую поддержку?
- О: не то, чтобы я в курсе…
- Q: Почему вы когда-либо освобождали объект, а не устанавливали указатель на него в ноль?
- A: Если ссылка не будет по-прежнему актуальна, потому что она немедленно выходит за рамки, то назначение не требуется.
- В : У того, что только что объяснил Олаф, есть название: культовое программирование грузов.
- A: Это была концепция, о которой я думал на этом вебинаре. Я большой сторонник программирования, основанного на фактах. , Tbh, мне пришлось искать, что означает «Cargo Cult». Да, я согласен. Но, как я уже сказал, если вы едете по своей дороге или есть безопасные водители, то теперь можно использовать FreeAndNil(). Но то, что я вижу в дикой природе, совсем другое. Помните, я часто работаю с внешними командами с очень разными наборами навыков. Многие из них не имеют тега «Сохранить драйвер» (пока)
- В : В статье в Википедии даже есть такое утверждение: «Навязчивые и избыточные проверки нулевых значений или проверка того, пуста ли коллекция перед итерацией ее значений, могут быть признаком культового программирования».
- А: лол
- В : Мы используем методы получения свойств, которые включают проверку присвоения переменной «f» и конструируют ее по запросу… иногда конструкция этой переменной «f» имеет разветвления (скажем, запрос к базе данных или построение формы), поэтому мы не создавайте каждую переменную «f» заранее. Мы также используем freeandnil, чтобы гарантировать, что последующие вызовы свойства обрабатываются и инициализируются надлежащим образом.
- А: конечно
- Q: FreeAndNil имитирует локальные переменные C++ unique_ptr. Delphi 10.4, наконец, представил RAII, так что теперь может быть более явный материал unique_ptr, но мне нужно поддерживать код Delphi 7, поэтому я продолжаю использовать FreeAndNil как unique_ptr, который отсутствует
- О: Всегда неприятно, когда приходится работать с кодом и для старых компиляторов.
- В : «Нет ничего плохого в том, чтобы оставить указатель на освобожденный объект» — правда? Вам когда-нибудь приходилось что-то отлаживать?
- A: Верно, не согласен с таким благовидным принижением навыков программирования, но я понимаю, что вы говорите, что «это может вызвать проблемы с отладчиком, поэтому вы не согласны».
- В : может быть, вы должны объяснить точную разницу между x.free и FreeAndNil(x). Я думаю, что не все здесь знают об этой разнице.
- О : FreeAndNil(x) free — это объект, такой же, как и x.free, но он также устанавливает ссылку на nil. Если вы не установите ссылку на nil, она все равно будет указывать на освобожденный объект.
- В : Поле класса, которое ссылается на объект, должно быть нулевым до тех пор, пока объект не будет создан, а когда объект освобождается, оно должно быть равно нулю. Этот разговор для меня бессмысленен.
- В: Примеры кода?
- О: Если вы посмотрите на слайды, вы увидите пару сообщений в блоге, которые ссылаются на код.
https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-dont-nos-programmes-en-pascal.html https://corneliusconcepts.tech/delphi-debates-freeandnil
- Вопрос: Я действительно не понимаю причины этих дебатов. Я думал, что это будет объяснение того, почему следует использовать FreeAndNil вместо использования .Free, а затем := nil. Здесь мы, похоже, обсуждаем использование FreeAndNil для объектов, которые я никогда не создавал. Кажется, я потерял сюжет!
- A: Обсуждаются плюсы и минусы использования FreeAndNil и наличия неназначенных ссылок.
- В : Я разработал SafeMM3 и обнаружил ошибку в FireMonkey. Деструктор использовал «Free» для ссылки, которая должна была исчезнуть, так как это все-таки деструктор, но тогда какая-то операция SetFocus ходила по оборванным указателям. Редко можно быть уверенным, что последняя операция над ссылкой действительно последняя.
- А: хороший момент.
- Вопрос:Дело в том, что NIL является реальным истинным значением в коде, и по этой причине будут проверяться такие ситуации (например, отклонение NIL, как утверждает Ник), и поэтому NIL не исчезает, поэтому имеет смысл NIL что-то изменить. убедитесь, что память действительно NIL, а не какое-то случайное старое значение из старых дней. Это особенно важно, когда вы пишете низкоуровневый высокопроизводительный код, но, очевидно, гораздо менее важно, когда вы в основном пишете высокоуровневый код, по сути, объединяя существующие модули в сценарии. У интерфейсов есть много замечательных применений, но иногда нам нужны просто указатели на записи или классы, и здесь очень важно отслеживать NIL или не NIL. Поэтому у FreeAndNil есть свое применение, но и у x.Free; и х:=ноль; Если последний выйдет из строя, то FreeAndNil может выйти из строя, и мы говорим о многопоточном сценарии,
- A: Хорошая мысль, Ким.
- В: Неправильно. Не всегда следует создавать классы в его конструкторе. Общепринято создавать объект при его первом использовании, а затем оставлять его созданным для повторного использования.
- О: Я вижу, что довольно много людей придерживаются обеих сторон этой точки зрения.
- В: Шаблон нулевого объекта (это то, что Ник назвал фиктивным объектом) подходит для инъекций, но не для многих создаваемых объектов.
- В : Недавно у меня произошел сбой из-за доступа к освобожденному объекту, который не был нулевым. Это действительно трудно обнаружить. Если переменная выходит за пределы области видимости, nil на самом деле не требуется, но вы должны очень тщательно проверить код, чтобы не использовать его впоследствии.
- A: На мой взгляд, если есть шанс, что ваша ссылка все еще будет использоваться позже, вам следует присвоить ей значение nil с помощью FreeAndNil.
- В : Действие := caFree Когда я это делаю, нужно ли ставить нулевой указатель? МойКласс := ТМойКласс.Создать; MyClass := nil, когда я использую Action := caFree
- В : Ключевой вопрос, вероятно, должен заключаться в следующем: есть ли истинные НЕДОСТАТКИ использования freeandnil?
- A: Скрывает вещи и может привести к ошибкам с ленивой инициализацией.
- В: Использование интерфейсов обычно не связано с управлением памятью, их смешение (при отсутствии подробной документации) — это целая череда катастроф, ожидающих своего часа. Я видел много кода, содержащего интерфейсные ссылки на объекты, которые были освобождены, когда счетчик ссылок обнулился. Дисциплина управления памятью, предусматривающая всегда явное освобождение с помощью FreeAndNil, кажется, должна быть по своей сути безопаснее.
- А: возможно
- В: Я думаю, что в многопоточном приложении имеет смысл использовать Assigned() и FreeAndNil(), когда экземпляры могут использоваться временно или взаимодействие с удаленными службами/серверами может быть прервано и потребуется повторное подключение к этим временным экземплярам.
- A: Да, я думаю, что некоторые из MVP согласны с вами.
- Q: Ada.Unchecked_Deallocation работает как FreeAndNil из коробки. То же самое и с процедурой Delete, она уничтожает переданный курсор. Жаль, что разработчики Delphi редко обращаются к другим потомкам Pascal для вдохновения.
- A: Я думаю, что существует гораздо больше исследований методов и нововведений всех языков — не только потомков Паскаля — которые вы могли бы понять. Например, объявления встроенных переменных (которые я лично ненавидел, когда они только появились) вдохновлены другими языками, в которых это реализовано. Они очень «не-Pascal», но, как оказалось, имеют некоторые очень явные преимущества, которые слишком убедительны, чтобы их игнорировать.
- В: Не всегда следует создавать все объекты класса в его конструкторе. Обычно, по крайней мере для нас, создавать объект(ы) только тогда и когда они необходимы, а затем оставлять их созданными для повторного использования. Затем, когда класс уничтожается, он должен уничтожить созданные экземпляры. Для этого жизненно необходимы Assigned и FreeAndNill.
- A: Ленивая инициализация, да
- Q: Придется бросить, но отличная дискуссия!
- О: Спасибо, Гэри.
- В : Для современных компьютеров цикл(ы) ЦП для FreeAndNil незначителен, даже для 3D-движков или чего-то еще. Это не 1980 год!
- О : как указали Ник и Томас, разработчик должен подумать, почему именно FreeAndNil, поэтому требуется больше циклов разработки.
- Вопрос:Я учусь разрабатывать мобильное приложение с использованием Delphi 10.4 CE FMX, и у меня много сомнений, и я не могу найти их нигде, кроме как в группах телеграмм или видео 99coders, где есть фантастическая дидактика, помимо Марсио, Гледсон Прего , Anderson Fiori и MobiusOne, которые нам очень помогли. Но этого недостаточно для такого старого приложения, как Delphi. Мои сомнения: 1) Каков правильный метод и где я могу уничтожить объекты (*), которые создаются в функции/процедуре в разделе VAR? (*) jsonarray, jsonobject, frame и т. д. >> 1a) уничтожают ли эти объекты их с помощью FreeAndNil, disposeOf, .free, = nil? >> 1б) какой самый лучший и эффективный метод уничтожения этих объектов? >> 1с) где правильное место (мероприятие) для их уничтожения? при закрытии, при уничтожении? 2) Почему delphi вызывает так много утечек памяти объектов, что мы уверены, что они уничтожаются?
- В : Это отличная сессия (Марко)
- A: Да, это кажется популярным.
- В : Не могли бы вы пояснить, почему FreeAndNil() не является потокобезопасным?
- A: Это не атомарно. Вы должны заблокировать ссылку перед вызовом FreeAndNil.
- В : «Висячие указатели» — взаимодействующая модель управления памятью должна гарантировать, что потребители объектов будут уведомлены об освобождении объекта.
- В : FreeAndNil устанавливает значение nil до того, как освободится — поэтому, хотя у вас может быть переключение контекста до того, как вы освободите объект, вы уже установите указатель на nil…
- Q: Если освобождение является последним действием, то Free(). Если одна переменная используется несколько раз, то FreeAndNill()?
- A: если вы собираетесь повторно использовать ссылку, то FreeAndNil
- В : Что на самом деле делает FreeAndNil? Почему .Free не устанавливает ссылку на ноль?
- A: Free проверяет ссылку, чтобы увидеть, что она назначена, и если это так, то она уничтожает объект, но все еще ссылается на уничтоженный объект. FreeAndNil дополнительно присваивает ему ссылку на nil.
- В: К сожалению, встроенные переменные по-прежнему не работают. если вы используете инструменты рефакторинга поиска или рефакторинга ссылок «после» встроенной переменной в модуле, это ломает эти инструменты 🙁
- A: Есть еще некоторые работы и RSP, связанные с рефакторингом и встроенными переменными. Рефакторинг (и такие вещи, как автоматическое переформатирование) могут быть проблемой для новых языковых конструкций.
- В : Одно конкретное преимущество Паскаля перед языками на основе C… требование объявлять секцию интерфейса И переменные перед использованием. Способ, который позволяет получить представление о коде, просто взглянув на него.
- А: да
- В : Найдите мой проект SafeMM3 в OSDN. В отличие от SafeMM и SafeMM2, он совместим с последней версией Delphi, протестированной на Delphi 10.2. Я нашел оборванные указатели в FireMonkey, созданные голым Free
- О: следите за оборванными указателями.
- В : А затем это преимущество было «скомпрометировано» объявлением встроенной переменной и даже выводом типа данных… Брззззз….
- A: Я люблю встроенные переменные.
- В : Где примеры?
- A: Я разместил несколько ссылок выше.
- В : вспоминаю, я пришел из клипера/гавани, где я начал работать в 14 лет и оставался там до 2021 года, когда я сдался и посмотрел усиленное видео 99coders, рассказывающее о Delphi, где название было примерно таким: «delphi is мертв?» и это показало, что вы можете многое сделать с помощью delphi, особенно для мобильных устройств (android/ios), лол
- В: Как вы поживаете при использовании DLL и передаче объектов в качестве параметра? Вы делаете копию объекта и отправляете ее обратно в качестве объекта результата?
- A: Это зависит, я полагаю.
- В: еще один вопрос от кого-то из Бразилии: 3) почему вы пытались использовать .DisposeOf, если вам пришлось вернуться к FreeAndNil()
- В : C++. У меня есть опыт работы с C++, поэтому меня так раздражает отсутствие подробной документации по интерфейсам Delphi.
- А: ах, да
- Q: 4) пожалуйста, приведите хороший пример использования freeAndNill(), эффективно устраняющего утечку памяти…
- В : Эти пункты поднимают идею владения / заимствования в Rust .
- О: Да, Delphi во многом вдохновила Rust.
- В: У меня нет вопроса, но я хочу поблагодарить вас за разработку Delphi. Спасибо)
- Ответ: Спасибо! Я рад, что Delphi тоже здесь!
- В : какой хороший источник для понимания структуры дизайна интерфейса
- A: Я считаю, что книги Ника Ходжеса обсуждают это.
- Q: Интерфейсы не ориентированы на многопотоковое исполнение. Есть только счетчик ссылок внутри TInterfacedObject. Но назначение интерфейса — это неатомарная операция, и ее нужно заблокировать.
- О : Да, в книге Далии это подробно обсуждается.
- В : Был комментарий о «пустой трате циклов процессора»… Сколько ассемблерных инструкций требуется для «x = nil»? Если это делается для нескольких объектов в каком-то цикле/цикле, назначение NIL может повлиять на производительность, если на переменные больше не ссылаются после их освобождения, но если на переменные могут ссылаться вне цикла позже, лучше знать, если они действительно ссылаясь на существующий объект.
- A: Проверьте представление процессора и посмотрите.
- В : MISRA C полностью посвящена программированию культа грузов. C позволяет однострочные операторы, но MISRA C запрещает их. Так что это довольно промышленная практика. Нечего стыдиться
- А: ах
- В: Хорошая дискуссия!
- О: Он оказался намного популярнее и вызвал разногласия, чем мы думали!
- В : @Nick, если вы никогда не используете FreeAndNil(), то в приложениях, основанных на событиях (не так уж и редко), как вы можете избежать создания объектов в неизвестные моменты и избежать создания их дважды или более? Типичным случаем является случай, когда пользователь нажимает кнопку и запускает потомка TThread. Что делать, если пользователь дважды щелкает одну и ту же кнопку, второй раз, когда 1-й TThread, запущенный 1-м щелчком, не завершен.
- A: Может быть, предотвратить двойное нажатие кнопки? Это кажется обоснованным беспокойством.
- В: Мне удалось создать экземпляр объекта с помощью «assigned». Я только освободил объект из памяти с помощью «action: caFree», но не указал «nil». Как это возможно?
- A: Если вы не вызовете FreeAndNil или явно не присвоите ему значение Nil, то free не обнуляет ссылку.
- В : пример, где FreeAndNil покажет ошибки в коде: С object.Free вы не получите исключение, если случайно используете объект. с FreeAndNil(object) вы получите исключение немедленно! пример: procedure TForm1.BT_Click(Sender: TObject); переменная сл: TStringList; начать sl:=TStringList.Create; попробуй наконец сл.Free; //FreeAndNil(sl); конец; // — // прочее // — if (sl.Text = ”) then sl.Text:= ‘Hello World!’; конец;
- А: спасибо
- В: Есть ли ситуация, когда мне нужно использовать освобожденный объект? (чаще мне нужно «обнулить» переменную без освобождения объекта). Или, возможно, FreeAndNil существует только для полноты, потому что x.free не может обнулить переменную. Спасибо
- A: На мой взгляд, я FreeAndNil, когда есть другие ссылки, которые могут ссылаться на него после того, как он равен нулю.
- Q: Ни один код не свободен от ошибок. Вы хотите, чтобы ошибки выходили из строя рано и сильно. FreeAndNil помогает отлавливать ошибки «использовать после бесплатного».
- А: правда
- Q: Я никогда не вызываю деструктор напрямую, это работа Free, не так ли?
- А: да
- В : Я почти всегда использую freeandnil на сторонних компонентах, никогда не доверяю чужому коду 😛
- В: Я не уверен, что прямой вызов Destroy на самом деле быстрее, чем использование Free. Просто потому, что Destroy — это вызов виртуального метода. Кто-то должен предоставить какой-то ориентир, чтобы доказать это.
- А: правда
- Q: Создание объекта при первом использовании может создать много проблем при попытке что-то сделать с этим объектом. Я столкнулся с этим при добавлении некоторых функций в InplaceEditor TCustomGrid.
- В : В идеале было бы программировать так, чтобы компилятор помогал решать проблемы… Вместо этого здесь много дискуссий о навыках программиста.
- В : Глобальные ссылки на формы — IDE автоматически создаст глобальный указатель на формы…
- В : Так вы называете IDE сумасшедшей? В от Джима? Это просто грубо!
- А: 🙂
- В: Говоря о «не-Pascal» встроенных переменных, Ада с самого начала имеет блок declare-begin-end. Так что это не «не-Паскаль», просто вы еще не знакомы с Адой. Но на этом Ада не заканчивается. В Delphi совсем недавно появились «встроенные переменные», в то время как в Аде разработчик чаще пользуется вместо этого «встроенными константами». Действительно, если что-то инициализируется в начале блока, скорее всего, оно не изменится до конца области видимости. Отметка «постоянных» элементов помогает удобочитаемости и рассуждениям.
- A: Да! = Паскаль. ️
- В : Если вы постоянно используете FreeAndNIL, то при его использовании не требуется дополнительного цикла разработки. Это только тогда, когда вы не последовательны в своем использовании…
- A: Я полагаю, что это правильное замечание.
- В: Могу ли я сказать, насколько мне понравилась эта наводящая на размышления дискуссия? Благодарю вас!
- О: рад это слышать.
- В : Какие книги Далии Прашникар вы бы порекомендовали по сегодняшней теме?
- О: https://dalija.prasnikar.info/delphimm/index.html
- Вопрос: Я брошу свои два пенни на ринг…. с заявлением… старайтесь не использовать их и, конечно же, не используйте их более чем для одной цели….. просто MHO
- О: Да, это и мое мнение, но, видимо, не все с этим согласны, отсюда и дискуссия.
- В : какой из них использовать для уничтожения: .free disposeOf =nil freeAndNil() ??? какой из них действительно освобождает память, и мы избавляемся от дерьма «Memory Leak»? набл.: delphi 10.4 CE / FMX / Mobile
- В : Как называется книга Далии?
- О: https://dalija.prasnikar.info/delphitspatt/
- В : Этот вебинар был отличным. Честно говоря, я не ожидал многого, но, откровенно говоря, это был один из лучших вебинаров за последнее время…. Побольше таких же пожалуйста!!
- О : Отмечено. Рад, что вам понравилось.
- В : Никогда не использовал FreeAndNil. Никогда не будет — если только Ник не начнет его использовать 😀
- А: ах
- В : Очень интересное обсуждение работы с переменными-указателями… Обычно я удаляю или возвращаю указатели в память после их использования.
- О: Да. Это закономерность.
- В : Полностью согласен с предложением Хольгера: может ли Delphi перестать создавать новое приложение с формой, построенной на основе глобальных переменных? Конечно, стоит обсудить.
- О : Я тоже думал об этом.
- В: предоставленная вами ссылка не работает: https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-don’t-nos-programmes-en-pascal.html — эта ссылка не работает ( ошибка 404)
- В : Спасибо, сеанс понравился!
- Q: Предложить сохранить и опубликовать чат тоже
- В: Придется бежать. Огромное спасибо!!! Отличная работа.
- В: Уничтожить в одиночку быстрее, чем бесплатно. Реализация бесплатного: «ЕСЛИ назначено (само), ТОГДА уничтожить»; так что, вызывая Destroy напрямую, вы пропускаете один CALL и одну проверку «If Assigned» — вы все еще вызываете виртуальный Destroy…
- Q: Если вы хотите проверить потокобезопасность интерфейса, напишите потомок TInterfacedObject, который вызывает Sleep(10) в AddRef и Release. Я написал ссылки без блокировки с помощью примитива Compare-And-Exchange, который проходит этот тест. Я, вероятно, тоже могу сделать поточно-безопасную слабую ссылку
- В : Честно говоря, благородные «гуру» не ответили ни на один из моих вопросов. Есть 11 мужчин и женщин, которые являются черепами Паскаля / Дельфи, и я начинаю и иду из клипера / гавани, я хотел бы вашего внимания, даже для того, чтобы я чувствовал себя как дома!
- В : Я всегда стараюсь, где это возможно, создать объект и освободить тот же объект в одной и той же подпрограмме, так у меня будет гораздо больше контроля и гораздо меньше шансов на проблемы с памятью и ссылками и т.д.
- Q: Мы много говорили об использовании интерфейсов для автоматического управления памятью… что сейчас с управляемыми записями? Можем ли мы сделать RAII в Delphi… есть ли другой путь?
- A: да, RAII вводит это.
- В : Если бы вы собрали вопросы и ответы, которые вам задают, и опубликовали бы их, было бы превосходно.
- A: Подумаем об этом.
- В: Я присоединился немного поздно, извините, если этот вопрос обсуждался ранее; если вы в любом случае освобождаете дочерний объект, как в (ParentObject.childObject), а затем вы освобождаете родительский объект freeAndNil … может ли это быть небезопасным из-за того, что время, необходимое для освобождения каждого объекта, может пересекаться и быть последовательным?
- О: Хороший вопрос. Даже если вы обнулите ссылку, объект все равно будет нести ответственность за освобождение своих дочерних элементов, в то время как дочерние элементы используют шаблон уведомления для уведомления родителя, когда они освобождаются.
- В : Если вы запускаете поток по нажатию кнопки, кажется очевидным, что вы должны быть готовы запускать несколько потоков :-), вы не освободите общие объекты в таком потоке. Или… вы отключаете кнопку.
- А: да
- В : насколько дороже FreeAndNil для ручного бесплатного использования с последующим ручным назначением бесплатного?
- A: С точки зрения процессора он не требует многого, но что он сообщает.
- В: Мне понравилось живое обсуждение настоящих экспертов в области программирования.
- В : Delphi RTL использует GOTO 🙂
- А: да
- В: Спасибо, подробнее об этом, пожалуйста. +1
- А: конечно
- В : Если вы уничтожите объект TJSONObject, он также уничтожит все объекты «GetValue as TJSONString»?
- В: Предложение… не можем ли мы просто сказать «не использовать с»… давайте сделаем то, что он пытался сделать… что есть в других языках… и что мы могли бы начать делать вместо этого с современным delphi в этом направлении
- Вопрос. Разве события нажатия кнопки не доставляются в результате получения GetMessage из очереди потоков пользовательского интерфейса? Второе событие щелчка не будет доставлено до тех пор, пока не будет обработано первое, если только оно не будет создано программно, что может вызвать проблему повторного входа. Что мне здесь не хватает?
- В : Больше переходов в RTL, так как я начал оптимизировать некоторые системные функции без ассемблера 😉
- В : Не так просто просто отключить кнопку, потому что это сложнее. Я использую такое понятие, как «требование» из функционального программирования. Таким образом, при первом нажатии кнопки создается запрос с подсчетом ссылок, посвященный «первому щелчку». Затем поток может сделать некоторые вещи и опросить свой собственный «запрос», чтобы проверить, востребован ли он. А войдя в Synchronize, также проверьте, действует ли еще это конкретное «требование». Когда кнопка нажимается во второй раз, старое требование помечается как устаревшее, и развертывается новое требование. Таким образом, первый поток получает сообщение: уходите, вы нам больше не нужны.
- В : Пожелание: локальные, статические переменные, которые сохраняются при вызовах (в настоящее время используются назначаемые локальные константы).
- В: Спасибо