Leaderboard

Yesterday I managed to release V15.1 of MMX Code Explorer. Besides some bug fixes it implements a couple of feature requests from MMX users. The parser system got some significant overhaul, albeit it is still far from perfect. At least there will be less errors in the MMX Explorer tree as well as better support for generics and inline var/const. I rated the improvements worth a bump in the Minor Version number.

There is plenty to talk about. It is not just about FreeAndNil, but about constructing and destructing object and all the fine print around that process. While on the surface this topic seems simple enough and that there is nothing to talk about, it is rather complex topic and many developers, even experienced ones, easily forget about some very important facts around this topic that can cause serious issues in applications.

Amazing that there's anybody left that doesn't know that Free does the nil check itself.

I am signed up only for the fact that Allen Bauer comes to the party.

And that takes us back to Dalija's point. Understanding needs to precede coding.

Actually, obj.Free already checks for NIL, so the if statement is unnecessary. FreeAndNil also does something different than the name implies: procedure FreeAndNil(var Obj); var temp: TObject; begin temp := TObject(Obj); TObject(Obj) := nil; Temp.Free; end; (That's the old, non-typesafe version, if I remember correctly) So it should actually be called NilAndFree because it first sets the Object reference to nil and only then calls its Free method. That has some implications if there is code in the destructor / called from the destructor that references the object instance via the same pointer (which shouldn't be done but I have seen it been done.

I also use FreeAndNil - if I ever forget that an object was already freed with .Free, app might be working fine or give an AV "sometimes". When I use FreeAndNil and by mistake try to use freed object later, I am sure it always gives AV. I would not use FreeAndNil in time-critical parts, but there are almost none in my apps.

Oh, in that case, absolutely. Guess I should watch it.

What did I miss? What I understand is that It is not part of the language, it is just a regular method from the standard library Earlier versions did have an untyped parameter and let you pass in things that were not descendants of TObject If that is all, how can you even have an opinion on that? What is there to talk about? Can somebody get me up to date with just one or two sentences? Many thanks.

But it also removes all Bookmarks in all open files !!! That's why I pointed this out.

Update: Reformatted the Mac, installed maOS Big Sur, an older version of Xcode. Things now work as advertised with Delphi 11. But I am wondering what the underlying problem is and if anyone has managed to make this configuration work. The Mac is an M1 (2020), not an Intel machine. This configuration works: Delphi 11 plus November and January patch Hardware: M1 (2020) Mac running macOS Big Sur Xcode 13.2 Not working configuration: Delphi 11 plus November and January patch Hardware: M1 (2020) Mac running macOS Monterey Xcode 12.5.1 / 13.0 / 13.2 / 13.4.1

One of my former coworkers started to call herself the Little Indian (she was of Indian descend and really tiny) after she heard one of the developers talking about little endian vs. big endian format. Somehow it didn't get old, we had a laugh every time she said that (the reason possibly was that we were drunk most of the time, playing Total Annihilation after office hours) Those were the days ...

Oh, yes! There is Big Indian and Little Indian format, eh?

Not about Marshmallow, but .... Looking for some "dynamic" ORM. Makes it sense? Have some DB Wizard for adding columns "on the fly" (usable in reports, for example) But in ORM universe I have no idea how to do that. Thanks