Leaderboard

I wouldn't use any of those solutions. Because that is not golden rule. On the contrary, for reference counted types you would almost always use const to avoid unnecessary reference counting overheard. Problem is not in the method that has const, problem happens at call site. As such it should be handled at call site. First, handling it at call site allows you to trigger reference counting only for references that really need it, next, you will avoid situation where performance will become an issue and someone will go and change method signature according to common practice - using const and will inadvertently break code. Far better solutions than 1. or 2. are using additional variable instead of constructing instance during method call, This is also easy rule to remember - don't create anything inplace. Next solution would be explicitly typecasting TFoo.Create as IFoo And the last one, I like the most because it prevents you to make reference counting mistakes in other code, too, is to have class function that will create instance and return it as interface reference. As for finding all places where you can create possible problem and you need to fix it, simple search and replace can go a long way. For instance - if you have class function New, you can just replace TFoo.Create with TFoo.New and if have same parameter list, you are good.

Yes. Since such coding pattern is not too common in Delphi because of its manual memory management. So you either cannot use it at all, or you are creating objects and passing ownership which is not the most common scenario, or you are creating reference counted instance where inplace creating creates problems. There is no performance penalty here. You need to trigger reference counting when creating new instance. That is the original issue you are solving. All you can do to prevent accidental misues is great, but sometimes people just need to use their brains and think what they are doing.

Long awaited release of powerful open-source documentation generator for Pascal code is out. Get it New website, using Jekyll, generated from our wiki, see https://github.com/pasdoc/pasdoc.github.io (Michalis) Moved everything to GitHub Ancestors list is now affected by external class hierarchy (Michalis) Markdown support (Fr0sT-Brutal) Supporting bold, italic, inline code, multi-line code, URLs, lists. @note and @warning tags (Bi0T1N) @url tag (Bi0T1N) Allow to lowercase output of @nil, @false, @true by --lowercase-keywords (Bi0T1N) Automatically detect flag like [xxx] at @param description. See here for example. (PifPof) Scan implementation section of a unit in addition to the interface section (Fr0sT-Brutal) Parser improvements to correctly handle some special cases: reading chars > $FF, "*.inc" includes, files with Mac-style line endings (Fr0sT-Brutal) Mem leaks fixed (Fr0sT-Brutal) Tag parameters now could be multiline without enclosing parens by means of "line feed" character "" (Fr0sT-Brutal) Read additional command-line options from file (Fr0sT-Brutal) --auto-back-comments command-line option (Fr0sT-Brutal) pasdoc_gui opens a file given at command-line, opening WWW browser is optional (Fr0sT-Brutal) @longcode without markers fixed (Michalis) Support for namespaces in units in @links (Fr0sT-Brutal) --ignore-marker option (Fr0sT-Brutal) Test suite fixes and better documentation, in particular for Windows users Catalan translation updated (Xavier Martínez) Delphi Tokyo files, to compile all projects and packages (Carlos Feitoza Filho) Brazilian Portuguese translation updated (Carlos Feitoza Filho) Parse identifiers declared as &xxx, where "xxx" may be a reserved word. Possibility to specify additional files using -A or --additional (just like introduction or conclusion, but you can provide any number of items) (Alex Merkel) Added de.utf8 (German with UTF-8 encoding) Automatically remove %region and %endregion from comments Show visibility (public, protected, private...) inside records too (it is meanigful for advanced records) Implement in pasdoc_gui options to (Michalis) customize HTML head and body set external descriptions file configure identifiers excluded from auto-linking Rename "internal" to "nested" to describe this language feature. Because that is how it's called in official docs ( http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Nested_Type_Declarations, https://www.freepascal.org/docs-html/ref/refse41.html ) and the "internal" word has traditionally different meaning ("something not supposed to be visible/used from the outside"). (Michalis) The automatic tests are now easier to run and check (see tests/README.md) (Michalis) @raises and @param is now supported at properties as well as methods. Actually, it's supported everywhere now, but it makes sense only at properties and methods now. (Michalis) Tipue (client-side search) improvements: we have upgraded to use Tipue 6.1, which highlights the found terms we strip HTML from Tipue index, which makes the "search results" page correct Fix handling SVN fixed-length $Date:: Parsing of $if and $elseif expressions, like defined(MSWINDOWS) or defined(UNIX) (Michalis)

For all who want to try to get the DDevExtensions Delphi IDE plugin to work with Delphi 10.4 can now clone the DDevExtensions git repository. It contains the project files for Delphi 10.2 and 10.3. I'm not able to help with any Delphi 10.4 issues, so you are on your own. GitHub repository: https://github.com/ahausladen/DDevExtensions

There are subtle changes with new versions of windows. Getting the actual windows version is much harder than it used to be since Windows now fakes old versions to keep old applications happy. Auto running from the registry is harder if your application has admin rights, since that is something hackers try to do to gain admin rights. There must be a list of these things somewhere, these are just two in the old application I'm maintaining today. But generally, Delphi applications compiled 20 years ago still run today, as do new applications compiled with 20 year old compilers (mostly). Never used .net, but I know security holes are fixed every month, and Microsoft keeps breaking Delphi 2007 by regularly deleting the Borland.*.Targets files from the Framework directory. I would never sell an application that Microsoft can so easily break. Angus

100% this - any other program built with a programming language that directly is built ontop of winapi works as well - you only need to change applications in order to use and embrace new features or recommendations (such as not storing configuration or user specific data next to the binaries in programfiles)

There have been changes in Windows that required updates to the applications. For instance UAC introduced with Vista. Occasionally, there are also some other tweaks in Window that can cause some "minor" issues and require code update. It is that Microsoft has really great track record of providing compatibility options for older applications, so even very old applications can keep running. but this is more Windows feature than Delphi one. It helps that Delphi mostly relies on very stable core WinAPI, and that it creates single executable. But on other platforms Delphi apps don't have such longevity.

A question for Delphi developers who also use .Net: I'm reading this OLD (2008) Marco's blog and the comments: https://blog.marcocantu.com/blog/delphi_native_code.html and wondering if it's still the same today: that .Net world changes so fast they need to keep updating to latest framework versions of old stuff is not working anymore, opposite of Delphi? My oldest project is running for 15+years, and except for code updates to use the latest Delphi feature, I don't remember any Windows changes that I needed to take into consideration or project would not work anymore. Was I just lucky and there was a breaking change in Windows where Delphi projects had to be updated or Marco is still right about Delphi today - it just works, while others don't?

Very interesting project. But I worry that even if solved successfully from a technical perspective it may not work for the user. The problem is that the eyes get used to the dim light (retina diameter widens) and then when the screen image suddenly changes to a brighter level, yes, you may be able to bring up the room lightling in response, but your eyes do not react very quickly so you will still feel that the screen is "glaring". In fact because the room lighting has now also suddenly lept up in brightness you may find the overall experience even worse than before.

ZEOS 8.0.0 (trunk) svn 7310 NEW component ZMemTable https://zeoslib.sourceforge.io/viewtopic.php?f=50&t=73319&start=195 https://sourceforge.net/projects/zeoslib/ https://github.com/marsupilami79/zeoslib There have been a few fixes. Feel free to download, testing, use, submit comments. Michał

There were a few changes to Windows that required changes to Delphi programs but these were mostly minor and I don't remember most of them. One that comes to mind was that the known ways to prevent the screen saver from activating stopped working one after another. I think I had to change that code at least 3 times to make it work for XP, Windows 7 and then Windows 10. Then of course there was the major headache of UAC Virtualization and the corresponding entries to the manifest. But that was mostly because I did not keep up with the Delphi versions so I had to fix Delphi 2007 projects to manage these correctly. And more recently there was high DPI and scaling. Again, these could be solved at least partly by updating to the latest Delphi versions. I have no experience with dotNET, so I can't compare.

for me... 21 years of freelance development.. zero changes due to Windows issues. But.. I use third party components; so, I ignore if really that components has been updated due to Windows changes. I means 'complex' components like reportBuilder, or exporters to Excel..

Alternative to what?

> There is no performance penalty here. You need to trigger reference counting when creating new instance. That is the original issue you are solving. You have misquoted me. I didn't say that original problem you are solving is performance, but that you should not worry about performance with using New because you cannot avoid initial reference counting trigger for reference counted instances. And original issue with const is that it does not trigger reference counting when creating object inplace. Performance comes to play, when you don't use const but in that case you don't have to bother using New either. Yes, there are other places where reference counting can bite you... but you can do whatever you like. Additional issue with 1. and 2. is that not all code is under your control. Education is the first thing you should do, regardless of other approaches. Keeping developers in "stupid" mode is never smart thing to do.

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

Sorry, but I have to report a few bugs/regressions which have crept into DEC: These led for the following cipher algorithms failing their unit tests on x64: Blowfish RC6 Q128 In addition there was a bug which prevented compilation on x64 completely. Good news is: these are all fixed and available in development branch on GitHub (see above link). Have a nice evening TurboMagic

The only way to do that is to make the memory area MIMIC a real TBytes, by adjusting the size of the GetMem() allocation to include a fake TBytes header whose reference count is set to 1 or higher so the method doesn't try to free the allocated memory internally as it passes around and uses the TBytes. For example: type // these are defined only in the System unit's implementation, so // they need to be defined manually in your code... PDynArrayRec = ^TDynArrayRec; TDynArrayRec = packed record {$IFDEF CPUX64} _Padding: LongInt; // Make 16 byte align for payload.. {$ENDIF} RefCnt: LongInt; Length: NativeInt; end; var MemBlk: Pointer; MyByteArr: PByte; begin //GetMem(MyByteArr, DesiredSize); GetMem(MemBlk, SizeOf(TDynArrayRec) + DesiredSize); try PDynArrayRec(MemBlk).RefCnt := 1; PDynArrayRec(MemBlk).Length := DesiredSize; MyByteArr := PByte(MemBlk) + SizeOf(TDynArrayRec); // fill MyByteArr as needed ... Something(TBytes(MyByteArr)); // ... finally //FreeMem(MyByteArr); FreeMem(MemBlk); end; end; If that is not an option, and changing the method (or calling a different method) is also not possible, then your only remaining options are to either: - copy the GetMem() data to a temp TBytes, and then copy it back afterwards if needed. - change the GetMem() allocation to TBytes to begin with.

Nothing beats pointers to arrays for InterOp - even today.

No it still doesn't work, and I realize I forgot to create an issue about it. Now it is there: https://quality.embarcadero.com/browse/RSP-32362

I had created the report in Quality Central already ( RSP-32335 ). I also attached your Project1.dpr with the report.

Tangential story here: I started working at this new company earlier this year. My first programming task, as it were, was to move this app from a WinXP VM to a Win10 VM. That's really all it was supposed to be. It seemed to work fine in XP but kept randomly failing in Win10. I guess several people had "researched" it for a while and had concluded there were certain problems, and they gave me a bunch of directions and things to test. Regardless, they thought it should only take a couple of days but may need a little tweaking in the app that was controlling things. So I started to dig in. First discovery: they were using a Windows app -- Version 1.0 -- that ran OCR on a big batch of forms that were scanned in and delivered to us as PDF files. This was a batch-mode process, so they had a control program that stuffed keystrokes and mouse events into the Windows message queue to control the app. I guess they had a lot of variance in the timing because everything had a 5-sec delay. Except the OCR function itself, which had a 45-second window. It frequently timed-out. Second discovery: all of that "research" people did was useless. It turns out, they were making observations on a folder thinking it contained files that were being scanned and then imported into the system. Turns out the stuff in this folder was more of a "discard" pile of slag left over as part of the OCR process. The fact that the app kept crashing at the same apparent point made it look like it was choking on one particular thing, which appeared to be some failure to rename a file. Later on, I figured out the failure was because it failed to rename MOST of the files, whereas the last one they thought was the problem was actually done correctly. An early thought we had was maybe this old app had problems running in Win10, so we contacted the company to buy an upgrade. The company has a page with a "Buy Now" button, but it goes to a form with a bunch of questions that are sent to a marketing guy who was trying to determine what the optimum solution might be. We just wanted the latest version of the same app, but they refused to sell it to us. We didn't say exactly how we were using it, and I suspect our use violated their license anyway, which some others at the company also suspected. Instead, the marketing guy was trying to sell us a hosted version that we estimated would cost us about $10k/mo. Never mind that it wasn't HIPAA or PCI compliant, which we required. Their self-hosted solution was around $75k from what I could tell. The only thing I could see for sure was that the old app wasn't 100% reliable running in the Win10 environment; it def. had problems. So I started looking around for another OCR solution. I found one from a British chap that cost under $100 and was a Delphi library (not a DLL) that had no license restrictions that might affect our use. I hooked it up, did some testing, and it ran amazingly fast. When I cropped part of the page to restrict the scanning to the part with data we wanted, it went even faster. The original solution took 6-8 hours to process most batches of data we got, while this one completes the same input data in 20-40 minutes. The other thing I discovered about the original code was that the error handling was worthless. (I've found that in a lot of our code now.) I got it working and discovered a TON of errors were happening AFTER the OCR process ran, and that implied about 25% of the data it scanned was not valid or did not correlate with known data as it should have. I guess it was getting a lot of false hits because it was scanning the entire page, which often had weird artifacts that matched things we were looking for, only they were in the wrong place on the page, so the neighboring data it captured was wrong or missing. I rewrote the whole damn thing in a way that allowed us to switch between the two OCR engines. The new library worked a whole lot better. The older one still worked; it was far more robust and didn't fail as often, but it still took hours vs. minutes. Management wasn't happy because it took me way longer than they expected. I was surprised they weren't concerned about the opaqueness of errors, poor scanning quality, or the overall execution time. Or even the fact that all of their initial assessments were 100% off-base. Oddly, someone who heard about how the original code worked expressed interest in maybe adapting it to do GUI-based testing. The mere thought of using the method they used here to drive this OCR app, but for more generalized testing, just made me shudder. Most of this software does not trap run-time exceptions, so it just terminates with useless messages like: "error reading item(0); attempt to read from address 00000026", or "error in numeric conversion: '' is not a valid number". This is after consuming tens of thousands of input records. Their solution: just step through it with the debugger. In 99% of the cases, it's bad input data.