Tuesday, January 26, 2010

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.

14 comments:

  1. Wise decision (I mean having it first and cutting it now), the important bit is you'll compile the RTL and VCL packages without it (as we could already remove it from our code). RIght?

    ReplyDelete
  2. @Marco,

    Correct. We've also removed all the explicit checks and conversions from all the internal compiler helper functions.

    ReplyDelete
  3. This is a technical question for personal interest.

    Can you not tell the difference between a unicode string pointer and an ansi string pointer at run time by checking the char/element size?

    I'm assuming that UnicodeString based strings have an element size of 2, AnisStrings have an element size of 1.

    If you need to know if it is UTF8, those have a particular code page.

    Or have I misunderstood something?

    ReplyDelete
  4. Fulcrum? It reminds me of the Mig-29. A decent, but not successful airplane. One of the "best airplane to protect your control tower" category. And because the much more powerful Su-27 Flanker was available also. Good luck. Hope it won't be "the best IDE to write applications for your own computer".

    ReplyDelete
  5. @Capt.

    Fulcrum: the pivot about which a lever turns.

    It's about leveraging the existing product and codebase.

    ReplyDelete
  6. Glad to see you're shedding this for Fulcrum. I can already hear the rejoicings from Andreas Hausladen... ;)

    ReplyDelete
  7. May I assume that you won't release any further updates for D2009/D0201 which have this directive dropped out of source/binary, correct?

    Michael

    ReplyDelete
  8. @Michael and @Allen:
    It would be nice to have the choice - an optional service pack/hotfix to remove STRINGCHECKS of rtl/vcl to D2010, at least.

    ReplyDelete
  9. Cross compilation for Mac and Linux? Please elaborate.

    Also, 64bit when?

    ReplyDelete
  10. LOL,

    just noticed I've written D0201 - should read D2010 of course ;-)

    ReplyDelete
  11. Hi Allen,

    that's a good and wise decision not to keep those intermediate adjustments. They just did what they had been needed for, as long as needed.

    Cheers,
    Arvid

    ReplyDelete
  12. I second the proposal to deliver an optional RTL - at least dcu if non packages, compiled with stringchecks disabled - for those needing high string perfomance.

    ReplyDelete
  13. Does this mean we will not see x64 in Fulcrum?

    ReplyDelete
  14. Personally I would have liked to have seen UnicodeString::t_str() continue to return const char*, because I just today installed a version of C++Builder newer than C++Builder 6 (circa 2002) and have never worked with Unicode strings before and am having a HELL of a time figuring out how to transfer strings back and forth among APIs that each want a different type: the Caption property of a VCL component now is a UnicodeString, and I need to pass its content to the Perl-Compatible Regular Expression engine which (as far as I know) still uses char*. This was easy with AnsiStrings that used char* under the hood, but how do I do it NOW?

    ReplyDelete

Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.