Requiem for the {$STRINGCHECKS xx} directive…

It’s time. It’s time to say goodbye to the extra behind-the-scenes codegen and overhead that was brought to us during the Ansi->Unicode transition. We’ve shipped two versions with this directive on by default. The Ansi world is now behind us. It’s only real purpose in life was to assist C++Builder customers to more easily transition to C++Builder 2009 and 2010. There are some rare cases where an event handler that was declared in a C++ form/datamodule with an AnsiString parameter *could* be called with the AnsiString parameter containing a UnicodeString payload. To guard against this case, since there was no way to detect this at runtime, was to be resilient to it. Agree or not, that was what happened.


As we’re working on Fulcrum, the next RAD Studio release with a focus on cross-compilation for Mac and Linux, we saw no need to burden these platforms with something that was designed for easing a transition that has not occurred on those platforms. I can say with certainty that the Mac and Linux targets will not be encumbered with this extra overhead. It is also highly likely that even the Windows target for the next release will also no longer support this directive. The source level directive will still be accepted without error, it will merely have no effect.

This will potentially affect C++Builder customers, but as long as the transition to Unicode has been made, it will have no affect. In the rare cases that this will affect some our customer still maintaining old projects that have not updated any event handlers that too AnsiString parameters to take UnicodeString params as appropriate. We hope to at least provide a warning when opening up the form or data module in the IDE to alert the user of this case. More details as we figure this stuff out.
So the bottom line is that we’re intentionally shedding this extra baggage and will not be foisting it on the Mac and Linux platforms, and most likely Windows will maintain parity. I’m already hearing a few cheers and shouts from the back…coupled with a few merely going “Huh? What is he talking about?” Just know that if you’re a pure Delphi guy, there is really nothing to see here… except that you may see a slight performance boost in your code… that that is, as I understand it, a good thing ;-).

So, {$STRINGCHECKS xx}, don’t let the door hit you on the way out…

• Preemptive snarky comments (with equally snarky responses ;-):
• I cannot understand why you did this in the first place!
• We all knew going in that it was sub-optimal. A lot of the other suggestions and solutions we had were far worse. Ignoring the problem wasn’t an option.
• I only use Delphi and don’t give a rip about the C++ folks.
• We care about them a lot. They give us money.
• Finally! I’ve been telling you this ever since D2009!
• Thank you, Capt. Obvious.
• I have D2010, are you going to issue a patch for this?
• Uh, no sorry. D2009 and D2010 are still in the thick of the transition. Folks are still moving to these versions.
• Get a spellchecker! You must be an incompetent dolt since you misspelled ‘xxxx’
• Yeah, I know, you’re perfect and don’t make any mistakes. Yep, I suck.