[fpc-pascal] Stack alias for ARC like memory management?

Ryan Joseph ryan at thealchemistguild.com
Wed Apr 25 14:16:40 CEST 2018

> On Apr 25, 2018, at 6:52 PM, Marco van de Voort <marcov at stack.nl> wrote:
> The problem is that the C++ object model is more complex and tiered because
> of it.  Also the Pascal class mode has complications of its own (like the
> multi stage constructor system and its link to exceptions) that might be
> additionally complicating when stressed over two very distinct use cases.
> Compare it with the situation with multiple inheritance. C++ supports more
> in theory, but interfaces are more convenient and cover most scenarios. Yes,
> full MI coverrs more uses cases, but are the added ones really used a lot?
> We must remain critical, and not declare C++ as the gospel
> And then we come back to real and preferably common usecases that are an
> improvement over the
> current situation.
> I've used quite a lot more of records-with-methods in the last two years due
> to a lot of OpenGL and charting related work, so I'm not as against
> extensions in this area than I used to, but I can't really imagine the
> practical uses yet, and I don't instantiate that many classes locally and
> kill them again.  Most messenger types are already records, and I can't
> remember any moment that it was a problem that they were not in the
> inheritance hierarchy. (Maybe streaming?)
> Mostly stuff like TStringLists for splitting strings, but those are not
> really the kind of high performance usage that benefits from being stack
> based.

Yes you're right. Like the example I posted it’s highly common to make array wrappers like TList and then kill them at the end of the function but this isn’t something you’d do in  tight loop anyways. I guess what gets me is knowing that what I’m doing is 100% for certain a waste (like calling GetMem) so it’s itches the programmer part of my brain that wants to be efficient at all costs. :)

Practically speaking the only time this will impact performance is with real time application and graphic processing or games. I’m looking my code now and it’s hard to find examples but there’s cases in the main loop (at 60fps) where I ‘m calling GetMem hundreds or thousands of times to allocate little helper classes that get used in functions. The best solution now is to reuse classes (which means storing them outside the function) and allocate once but it would be cleaner to not do that. 

> Yes, I can vaguely see some minor syntactic sugar benefits of a
> autoinstantiation object.  (preferably done in a delphi compatible way)
> Though IMHO improving the IDE wizards to create the skeletons more
> efficiently (declare-create-try -finally-release) is equally valid.

Sorry I don’t use the IDE or Delphi so I don’t know what goes on there.

> But I'm afraid this is all just language grafitti, where everybody wants to
> put its stamp on the language with a lot of little used extensions.

I get that and maybe you’re right. It’s hard to say when a pattern is so common it deserves it’s own place in the language. I see this as a minor optimization like “inline” and beyond that just syntactic sugar.

> The challenges that Pascal faces are for the most not language related.

It would be hard to get new programmers to adopt Pascal given how easy to use languages like Java, C#, Swift are these days. All the talking about manually memory management is a thing of the past for most programmers out there today. Pascal will get left behind but it can still survive as a low-level performant language like C++ so that’s where my motivations are for Pascal.

>> Look at the little code snippet I just posted using code from another post. It?s a good example of the kind of pattern I wanted to optimize. It?s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it?s actually a big save.
> You mean the faulty one that frees stream twice (once because it passes
> stream to en which frees it), and doesn't free stream if
> freeandnil(en) gives an exception because they are in the same finally block?

Then that was a bad example but the principle remains true. If you looked at the code you’d find that same pattern over and over again I’m sure.

>>> This is patently false. Both Delphi and FPC are used professionally.
>> Good news. :) That?s how it feels to me though. People are honestly
>> confused when you tell them you use Pascal in 2018.  I can?t point to
>> where it?s a good low-language but then they remind of c++!
> Well, actually if you said you used C++ for non system or high performance
> applications in 2018, I think you would get the same look.

True indeed. We’re clearly on the legacy end of languages so it would be wist to make the best of it.

>>>> I?ve already pretty much given up writing Mac apps with Pascal because
>>>> it?s so hard to keep up to date and Swift is better than Objective-C but
>>>> I?d like to keep using it for games if I can.  At the end of the day I
>>>> really want to be able to say at least Pascal is a good low-level language
>>>> for writing fast code but in the face of C++ that?s kind of dubious claim.
>>> The dubious claim is the suggestion that detail language features are the
>>> main cause for language uptake. It isn?t.
>> True. Pascal is basically dead on Mac because Apple has made it so hard to
>> access their system frameworks.
>> I made a parser to convert objective-c to
>> Objective Pascal but it?s such a hassle to keep updated and Swift is
>> replacing Objective-C anyways.  Developers tools are hard to use outside
>> of Xcode also.
> I gave up Mac years ago, and from what I see in mails, installing still
> seems to be a big problem, mostly due to the binutils. Anyway, that is for
> somebody else to comment on. I simply don't know much about current Mac,
> since my last one was a G5, and I decided not to continue because Apple
> deprecated carbon.

Apple is doing everything they can to make it difficult for us. I’m not sure how all the Objective-C people are taking this but Apple is really pushing people towards Swift and they’ll deprecate everything eventually. Jonas did a brilliant job making Objective Pascal work but it’s just too great of an uphill battle.

> That said, I'm really happy that Microsofts next gen (UWP) platforms and
> store haven't really taken off yet.

	Ryan Joseph

More information about the fpc-pascal mailing list