 | Lars Fosdal on Security alarm provider Woonve… |
 | Thomas Mueller on Question got closed in May 202… |
 | Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
Posted by jpluimers on 2018/12/18
I just saw this code in the Delphi RTL enabled for RELEASE builds of the procedure TThreadPool.TQueueWorkerThread.Execute; code:
{$IFDEF MSWINDOWS} OutputDebugString(PChar(Format('Thread Exiting: %d', [ThreadId]))); {$ENDIF}
Never, ever do this.
If you code review code that contains it: ensure it has some kind of compile time DEBUG conditional around it.
–jeroen
This entry was posted on 2018/12/18 at 00:00 and is filed under Conference Topics, Conferences, Delphi, Development, Event, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
The Wiert Corner - irregular stream of stuff
baka0815 said
Why?
I understand that you should us compile time conditionals,but what is so bad about that?
jpluimers said
See the reply to Luca for more background information.
Indeed: always have a conditional define around it that is never turned on by default;
Luca said
Sorry, can you explain why? It’s slow or dangerous?
jpluimers said
Besides cluttering the output of people listening to OutputDebugString for their own debugging purposes, it can also have quite a performance impact.
More background information at:
Lenz said
This is debatable and a matter of perspective. The links that you posted doesn’t really make it more sound and don’t prove your point, which you did not explain.
I agree that particular OutputDebugString code in Delphi should definitely be disabled in release build. However, there are valid cases for OutputDebugString in release code – in a circumstances where a shared library (DLL) or a service may not have any other means of showing that a contingency has happened – ideally this should be something that can be enabled or disabled at runtime, but if not possible, then still, some feedback is better than none.
jpluimers said
I over-stated with intent. Of course there are always exceptions to a rule, but they are rare.
So I in practice: don’t.
If you really need it: make it configurable, but disable by default.
KMorwath said
When tools like DebugView hooks the call, serialization happens. Someone could be working on another application, and yours get serialized as well.
BTW, Widows has a new and more powerful tracing framework (ETW) – and it’s been available for years. As usual Embarcadero did nothing to improve its support for Windows but for a few visible widgets. ETW is far better than implementing your own log files, as it is designed to avoid big serialization issues. It’s also designed to be enabled/disabled as needed even in production.
See https://docs.microsoft.com/en-us/windows/desktop/etw/about-event-tracing
jpluimers said
That is cool! I did not know about it either, but it is definitely on my reading list now.
LEIF UNEUS said
From Rio back to at least XE8.
LEIF UNEUS said
Ok, It has been there since the introduction of the PPL library in XE7.
edwinyzh said
Nice find Jeroen. Which version of it?
jpluimers said
My guess is all. Since them disabling my MVP was done by just deleting the account that also held my Tech-Partner bits, I don’t have a full history of Delphi versions any more.