Leaderboard

You have a problem so you decide to use threads. you problems.2 have Now

ICS V8.58 added a new TSslX509Certs component allowing ICS servers to automatically order, download and install SSL/TLS certificates from various suppliers, including free certificates from Let's Encrypt, and commercial certificates for DigiCert, Comodo, Thawte and GeoTrust from CertCentre AG. It also acts as a private CA to issue local certificates. The TSslWSocketServer, TSslHttpServer, TSslHttpAppSrv, TIcsProxy and TIcsHttpProxy components can assign a TSslX509Certs component to support automatic certificate ordering of domain validated certificates with very little extra code. There is a new sample project OverbyteIcsX509CertsTst to demonstrate the TSslX509Certs component, which may be used as a standalone application to order X509 certificates from Let's Encrypt and CertCentre AG, and monitor the certificate orders database, and to issue own CA certificates. http://wiki.overbyte.eu/wiki/index.php/FAQ_Order_SSL_Certificates I'm about to revisit the TSslX509Certs component to support some Let's Encrypt changes like the new SSL challenge, so am interested in any feedback or suggestions from those that have used it, Even just the sample application which can be used to order certificates for other web servers or applications. Angus

I would argue that the same is true for single threaded code as well.

Is the unit in question explicitly mentioned in the project or is it a unit that is only used indirectly?

There's a Delphi version, too: http://deadlockempire.4delphi.com/delphi/

The GExperts Grep Search expert has various options to tell it which files to search: The current file All files in project All files in project group A directory list (separated by semicolon) That sounds like an exhaustive list, but it isn’t. Both, project and project group, were only searching files explicitly listed in the project(s). Files that were linked into the project using the search path, were not searched. Until now, that is: There is now an option to use the MAP file instead of the DPR file for project search. https://blog.dummzeuch.de/2019/03/03/gexperts-grep-can-use-the-map-file/

Welcome to the [BDE] club. That BDE installer isn't just the BDE but also installs the BDE components into the IDE, which is why it looks for RAD studio. After installation on the developer PC there's a file BDE_ENT.msi buried under ProgramData somewhere which is how you're meant to deploy it, not very obvious I know. (Easy to find with "Everything".) Alternatively you might consider a third party source. (For what it's worth we've extensively inspected and used this package, but treat it with the usual caution. It has some benefits in that it steps around/fixes the restrictions/problems that the BDE normally has on Vista and above due to the restrictions placed on Program Files, root folder and other system locations, that you might have to fix if you use the default Windows installer package.)

Indeed. In single-threaded code, good unit tests will show that the code obviously has no errors. In multi-threaded code, good unit tests will show that the code has no obvious errors. IOW, unit tests can only prove that your multi-threaded code doesn't work, not that it does.

Did the following: - went over the search paths thoroughly, removed everything that was not necessary (sources of the current project, bins of required libraries). - deleted the existing .dproj, let Delphi auto-create one - did a global search made sure there is one and only one version of my sources on the PC Still ignores unsaved pas. Worth noting that the project is not small. Tried reproducing the issue on a fresh blank project but failed to do so.

If only making good examples would be so simple.... it is so much easier to trash other people's examples... Joking aside... bad examples (or ambiguous examples) can make more damage than good. OOP is complex matter and not always straightforward. Ask 100 experts about it and you will get 100 different answers. My rule of thumb is learn about OOP, design patterns, testing and then apply common sense over it. If some rules collide, then apply KISS (Keep it simple, stupid) and YAGNI (You aren't gonna need it) and DRY (Don't repeat yourself) before any other principles. If it seems too convoluted or you don't have clear understanding why... better don't use it than use it in a wrong way. That does not mean people should not strive to learning and understanding better practices. In that context, primary goal of encapsulation is protecting implementation details that can change to avoid subsequent changes in consumer code. When you write your own classes you are the boss, you can decide what is implementation detail and what is not. Of course, you have to be careful about those decisions because you will have to live with them for a long time. When you consume other people's classes you must avoid using things that are not part of public API. Since it is not always possible to hide all implementation details, it is possible that not everything that is publicly accessible is really part of documented public API. Unless public API is clearly documented, sometimes it can be hard to know what is implementation detail, and what is not. Experience can help, but it is hard to give any good general tips on the matter - it all depends on the actual code. And this is where original question came from - what is implementation detail in some code and why is better to use some construct comparing to another. Another thing to keep in mind is that OOP depend on the language. What fits in one, does not fit well in another. In Java encapsulation means having geter and setter methods for everything accessible - because Java does not have properties. If you expose field directly any changes in access logic that has to go through geter or setter will require changes in consumer code - because Java expects parens () when you access method. In Delphi you might as well start with directly exposed field... changing that into property will not change consumer code (unless you add read or write restrictions) and adding geter or setter methods will also have no direct impact on consumer code. Of course, most Delphi developers will use properties instead of directly exposing fields, but this is more of common practice than actual requirement for fields that will be publicly accessible - part of the public API. I could probably go on for days... but I have other things to do... 🙂

BTW, OmniThreadLibrary's TOmniBoundedQueue was implemented in 2008. Then we needed about a year to find few weird boundary conditions where the code would crash and fix them. After that the queue was working perfectly until 2018, when I found a race condition which caused the queue to say "sorry, can't add an item, the queue is full", when the queue has actually just become empty. Nobody noticed the problem in the meantime, we all thought the code is perfect, and the unit/stress test did not test for this specific scenario ... Writing lock-free structures is harder than you think. (Applies to me, too.)

Interesting article, thanks for sharing it

I think such an HPPEMIT statement should not be needed at all. Delphi .PAS files output .HPP files, not .H files, when compiled for C++Builder, and there is no need for a .PAS file to ever HPPEMIT a reference to its own .HPP file.

I can confirm the semicolons are required, in ALL C++ versions and compilers. Typedef statements need to be terminated by a semicolon, just like any other statement in C++.

If you can live with FIFO LIFO/FILO/stack semantics then you can use Windows SLists. They're lock free and can be used with multiple readers and writers.

Non-implementation detail = the interface declaration - i.e. the black box UI - the what. Implementation detail = how an interface has been implemented - i.e. the inside of black box - the how. You want to use the first, and avoid relying on details from the second.

That's the name of the executing process. Asker wants to know about external processes.