Leaderboard

The new GExperts version still supports all Delphi versions back to Delphi 6 (with the notable exception of Delphi 😎 and even the Delphi 11 version is no longer in Alpha state (but it’s still beta, there will be glitches!). Support for per monitor DPI awareness should now work (in Delphi 11, and definitely better than in the IDE itself). There are even a few new features ... Read on in the blog post.

I'm OK, guys, thanks for asking. Not Corona, but I've spent some time in the hospital nonetheless.

Well, this is a private research-project about the EU Covid-certificates. I wanted to know how that stuff works and how the pieces are glued together. After a wild mixture of very interesting and also some nasty hours, I got it working. I also learned about new data formats that were previously unknown to me (hello "cbor"). Many different techniques come together here: decoding the data from Base45 (yes, forty-five) decompressing the result using the zlib-classes downloading external supplementary files using the http-components hopping from the formats "COSE" to "CBOR" to "JSON" using OpenSSL to extract and validate the digital signature against the official public keys All of this is now integrated in a small and fluffy Delphi program. This client reads the personal/medical data from the certificate displays the specific information for "vaccinated"-certificates "tested"-certificates "recovered"-certificates reads the digital signature from the certificate verifys that signature using the public keys from the official trust-list to detect fraud is clearly not an official application ready for production use anywhere Important: Some, but not all code ist from me. The unit "cbor.pas" comes from "https://github.com/mikerabat/DelphiCBOR", the interface to openssl comes from "https://github.com/Arvur/OpenSSL-Delphi". Just in case you're interested and want to try it: Download attached zip-archive. It contains the complete Delphi-project as well as the value-sets and trust-list (see #3). You need to get your hands on the openssl-libraries "libeay32.dll" and "ssleay32.dll" (not included in the downloads). These libraries must be located in the same directory as the executable. By default "Win32-Debug" is the output-path for this project. If you decide to switch to 64bit, you should provide the matching libraries. This program reads the trust-list and the so-called value-sets from external json-files. These files can be downloaded using the button "Download supplementary data" (button starts download, gives no feedback, you must restart the program afterwards). The trust-list contains the list of currently valid public-certificates. The value-sets contain the translations from IDs (values) to readable strings. All the json-files must be in the same directory as the executable - and that directory must be writable. The json-files from today are included in the download. You need - of course - an EU Covid-19 health certificate (vaccinated, tested or recovered). Take any barcode-scanner to translate the barcode into textual representation: You should get a string starting with "HC1:". Paste that code into the windows that opened after pressing "Scan certificate". CovDemo_06-Feb-2022.zip

Because it has been designed correctly with ref, out and by value arguments handling the three different parameter semantics. C# is an example of how delphi should be, and the entire issue with this missing warning is because delphi is so badly designed in this area.

Head office is in Israel (if i understand correctly). And its a possible that the language of communication will be english (but a russian accent is possible too ) : https://www.mekashron.com/blog/ru/

Without the compiler enforcing it, it's next to pointless

Hi Thomas, Thank you once again for all your work on and support for GExperts. Greatly appreciated. Ian

But, Delphi out parameters have some unpleasantries and many developers choose to use var instead. https://delphisorcery.blogspot.com/2021/04/out-parameters-are-just-bad-var.html

From my point of view, it is wrong. For "var" parameters, I expect they are already initialized. For uninitialized variables, that are used as output, there is "out". https://docwiki.embarcadero.com/RADStudio/Sydney/en/Parameters_(Delphi) - Out parameters are frequently used with distributed-object models like COM. In addition, you should use out parameters when you pass an uninitialized variable to a function or procedure.

It does not have to look inside - it sees (immediatelly), that uninitialized variable is passed as "var" parameter. It means that I should initialize the variable, or change the procedure and use "out" parameter instead of "var".

If a variable is given to a method as var or out parameter that should be sufficient to rate that variable as initialized inside that method. If that would always issue a warning, you will have to make a redundant initialization just to make the warning vanish. I strongly reject this request.

In theory the chance of a 32-bit pointer being 0 is 1:2^32 while the chance for a 64-bit pointer being 0 is 1:2^64. That is quite a big difference. I am aware that this estimate is probably pretty wrong because the memory contents are anything but evenly distributed. If you have some spare time you can analyze the 32-bit code and find out if some other method called clears the part of the stack later used for sl with zero most of the time. Note, that the benefit of this research is just to ease your mind.

Hi David, for simple use cases, the generic collections are simpler. However, please consider situations where you need to add a bunch of methods such as CopyFromLeft, CopyFromRight, Each, GetPropertyValuesByNameAsCSV, and so on, to the enhanced list class. In this case I have two options, and I'll outline the pros and cons: Inherit from the generic TObjectList<> Pros: Can eliminate some of the typecasting, but not all, without techniques such as Curiously Recurring Generic Pattern the OP is presenting. Cons: From time to time, the compiler emits strange internal error and I'll have to restart the IDE. bloated EXE sizes. Inherit from the non-generic TObjectList Pros: No strange compiler errors. No strange bloated EXE sizes. Cons: In order to eliminate all typecasting for the list users, you'll have to make a derived class for each object. That being said, I might be wrong, but my gut feeling is using the non-generic TList/TObjectList is more comfortable, especially without the need to constantly restart the IDE. By IList, sorry for not being clearer, it's from Spring4D which is excellent, so it just occurred to me. I should have said TList<>.

Different languages have different set of features and also differ in implementations of those features. Properties in general are a tool that provides additional level of abstraction around encapsulation and enables future implementation changes while preserving stable public API. Some of the benefits are more visible in some languages than the others. For instance, if you have public field Name and you want to add some code around retrieving that field is easy to do in Delphi. You can rename field and move it to private section and declare public function Name to retrieve it. I Java, you cannot do such thing because calling method must include brackets. This requires refactoring all code that uses such field. If you want to add setter, you will break the code in any language. This is where using properties helps with encapsulation. They hide unnecessary implementation details and give implementing class to ability to change those without breaking user code. You can start with simple field backed property, which from performance aspect is no different than public field and you can add getters and setters as needed without breaking code. Without properties, you can also maintain stable API, but the cost is having getters and setters for everything and paying the price in performance. No matter how small it is, eventually it can add up. Additionally, code with simple assignment is easier to read than setter method. There are some parts of general properties functionality that Delphi does not implement, like different access levels for reading and writing, or some additional ceremony when declaring properties, especially in interfaces. Some of those could be improved to make properties more flexible, but lacking them is poor argument against using properties. In situations where you really need some functionality properties don't provide, you can use other ways to achieve what you need, but not using properties everywhere else because you cannot do something in rare occasions is also not very convincing argument. Arguments around name refactoring are not very convincing either. They compare name refactoring, where there is a bit more renaming in declaration. Now, compare that single place where you need to make additional rename, to refactoring all code in case where you need to replace public fields with accessor methods. When it comes to extra declaration code needed for properties with accessor methods comparing to only having accessor methods, think how much unnecessary getters and setter methods you need to write in cases where you could use field backed property declaration. Overall using properties results with cleaner code and having more functionality than you can have with simple fields or just accessor methods. The little bit of ceremony around the declaration is price I am more than willing to pay, to get all other benefits.

Heh, that doesn't even work properly for interfaces, even if they are not refcounted, You can make objects not being refcounted, but they would still live in an ARC environment, with al the possible problems and disadvantages. Note that your example contained a string constant, not just a non-refcounted object. Obviously you thought about it, but didn't think this through to the bitter end. So again: no they will not coexist easily.

You are really an expert in convincing others to support your ideas. Using a tone like that is certain to win them over. <g> I did not read the entire topic (7 pages an counting...) and I will not. If you had anything useful to say, then repeat it. But no matter what you wrote, I'll write it again: no, they won't easily coexist at all.

they would coexist just fine. No, they would not. Note one bit. The only objects that could co-exist would be manually and automatically refcounted objects. But normal objects are not refcounted, in Delphi (unlike in macOS and iOS). So again: no, they would not easily coexist at all!

I see you are an expert in making friends. <g>

Seems you have made up your mind that nothing good and optimal can come out of non native code. In this case, there is very little I can say to convince you otherwise. By the way, the current media player I use is written in JavaScript and it runs beautifully for me on both my Windows and Linux boxes.

Really? Do we have to go down this road again? ECDSA (Elliptical Curve DSA) <> EdDSA (Edwards Curve DSA). It has a lot of use cases as ECDSA and it is been used in Monero and Nano to mention but a few.

Really? I have seen highly performant programs including media players written in .NET and even JavaScript.

There is a modified version of SWIG that includes support for Delphi & Object Pascal - https://github.com/FMXExpress/swig-delphi But I've never used it. Another excellent tool which utilize CLang to convert C (not C++) header files to Delphi: https://github.com/neslib/Chet Another tool that does source to source conversion: https://github.com/WouterVanNifterick/C-To-Delphi

At least it already compiles to it.

Nooo! You can't stop this before it complies to godwin's law 😉

That is the "weird" right there. Definitively a good reason to avoid defined ordinal values in enumerations.