{"id":2584,"date":"2017-03-16T16:35:05","date_gmt":"2017-03-16T04:35:05","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2584"},"modified":"2017-03-16T19:42:42","modified_gmt":"2017-03-16T07:42:42","slug":"anatomy-of-a-utility-function-booltostr","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2584\/","title":{"rendered":"Anatomy of a utility function: BoolToStr()"},"content":{"rendered":"[Estimated Reading Time: <\/span> 5<\/span> minutes]<\/span><\/span>

Jaap Van Goor was asking on FaceBook about some seemingly strange behaviour when obtaining string representations of Booleans using the Delphi RTL<\/a>, which led me to revisit some familiar (and some not so familiar) old Delphi ground and take a look at the area involved in further detail.<\/p>\n

<\/p>\n

First of all, let’s quickly deal with the initial “problem”.<\/p>\n

Jaap was concerned to understand why ABoolean.ToString<\/strong> returned 0<\/em> or -1<\/em> rather than false<\/strong> and true<\/strong> (respectively).<\/p>\n

The answer is that the Boolean<\/strong> type is not really<\/em> an enum<\/em> (though RTTI identifies it as such) but a much more specialised type that has some things in common with an enum but also some quite significant differences.<\/p>\n

The symbols true<\/strong> and false<\/strong> are effectively compiler defined constants but with some additional caveats about what one of those particular constants actually means<\/em>. That is “True” is both a value (1) but also the result of an evaluation<\/em> of a value, where any non-zero value is “true”.<\/p>\n

Unless I’m mistaken, at time of writing it’s still not possible to use ToString<\/strong> on a variable of type enum, where-as you can on an Integer<\/strong>. Which is one clue that Boolean<\/strong>‘s aren’t quite the enums they might claim or appear to be.<\/p>\n

Friendly Advice <\/h2>\n

A couple of suggestions were made in response to Jaap’s post as to alternative ways to convert a Boolean<\/strong> into a more meaningful string representation. One of these was a function called BoolToStr()<\/strong>.<\/p>\n

Now, on the occasions when I’ve needed something similar, the needs are usually quite specific to the context of a particular problem. Sometimes you do want simply true<\/strong> and false<\/strong>, other times you might want yes<\/strong>\/no<\/strong> and on yet others on<\/strong>\/off<\/strong>, enabled<\/strong>\/disabled<\/strong> etc<\/p>\n

And of course you may want to localise these values.<\/p>\n

As a result I have always used a simple Boolean-indexed array for this myself, allowing me to specify the particular values applicable in a particular context:<\/p>\n

\r\n   const\r\n     BOOLSTR: array[false..true] of String = ('false', 'true'); \r\n   begin\r\n     \/\/ ..\r\n\r\n     s := BOOLSTR[aBoolean];\r\n\r\n     \/\/ ..\r\n   end;   \r\n<\/pre>\n
If the particular context has some wider scope than a specific block of code, then this of course can itself be wrapped up inside a helper method of my own, itself scoped as appropriate to the context.<\/p>\n
But I didn’t even recall ever having heard of BoolToStr()<\/strong> before, so I took a look.<\/p>\n
As a result I’m wondering now whether I had<\/em> in fact heard of it, looked into it and then deliberately purged it from my memory<\/em>!<\/p>\n
Brace yourselves, this isn’t going to be pretty.<\/p>\n
 Here be Dragons <\/h2>\n
BoolToStr()<\/strong> accepts up to two<\/em> boolean parameters.  The first is the one you wish to convert to a string representation and the second indicates whether you want to “UseBoolStrs<\/em>“.  If you indicate that you do not (the default if not specified) then you get 0<\/strong> or -1<\/strong>:<\/p>\n
\r\nfunction BoolToStr(B: Boolean; UseBoolStrs: Boolean = False): string;\r\nconst\r\n  cSimpleBoolStrs: array [boolean] of String = ('0', '-1');\r\nbegin\r\n  if UseBoolStrs then\r\n  begin\r\n    VerifyBoolStrArray;\r\n    if B then\r\n      Result := TrueBoolStrs[0]\r\n    else\r\n      Result := FalseBoolStrs[0];\r\n  end\r\n  else\r\n    Result := cSimpleBoolStrs[B];\r\nend;\r\n<\/pre>\n
So far so simple.  Well, down that particular conditional branch anyway.  If UseBoolStrs<\/strong> is false<\/em> then the result is simply plucked from a Boolean-indexed array.<\/p>\n
Where things get interesting and – frankly – messy and not a little bit scary, is if you have said that you do indeed wish to UseBoolStrs<\/strong>.<\/p>\n
In that case then the RTL goes scurrying off down a path that takes us through VerifyBoolStrArray<\/strong> (every time) and then returning the first value in one of two separate arrays, conditional on whether we’re converting a true or false value.<\/p>\n
VerifyBoolStrArray<\/strong> itself simply checks whether the length of these two arrays is not zero (i.e. empty) and if either one is then sets an length of 1 with an initial, non-localized default value in each (the constants DefaultTrueBoolStr<\/em> and DefaultFalseBoolStr<\/em> are defined as ‘True’ and ‘False’).<\/p>\n
\r\nprocedure VerifyBoolStrArray;\r\nbegin\r\n  if Length(TrueBoolStrs) = 0 then\r\n  begin\r\n    SetLength(TrueBoolStrs, 1);\r\n    TrueBoolStrs[0] := DefaultTrueBoolStr;\r\n  end;\r\n  if Length(FalseBoolStrs) = 0 then\r\n  begin\r\n    SetLength(FalseBoolStrs, 1);\r\n    FalseBoolStrs[0] := DefaultFalseBoolStr;\r\n  end;\r\nend;\r\n<\/pre>\n
Also of some interest is that in the TryStrToBool()<\/strong> function the implementation allows for the possibility that these arrays may have more than just the one entry introduced by the Verify<\/strong> function.<\/p>\n
But nowhere else in the entire RTL does any code modify or add to these arrays<\/em>.<\/p>\n
Nothing adds to them, nothing changes them.  Nothing.<\/p>\n
And the strings placed in the arrays are just regular string constants, not resourcestring<\/strong>, and are specifically commented as not to be localised.<\/p>\n
On the face of it then, it is all just unnecessarily convoluted and could simply be replaced by a simple lookup from a similarly boolean-indexed array:<\/p>\n
\r\nfunction BoolToStr(B: Boolean; UseSymbolicStrs: Boolean = False): string;\r\nconst\r\n  cStrs: array [boolean, boolean] of String = (\r\n                                               (    '0',   '-1'),\r\n                                               ('False', 'True')\r\n                                              );\r\nbegin\r\n  result := cStrs[UseSymbolicStrs][B];\r\nend;\r\n<\/pre>\n
(Ok, so I admit to a little additional finesse here.  :))<\/p>\n
But it bothered me.<\/p>\n
Why go to all this trouble if the arrays are only ever going to be setup in a particular way… ?<\/p>\n
Which led to a worrying thought and the realisation of the true horror lurking within BoolToStr()<\/strong>.  The reason for consulting these arrays rather than simply directly using the constants held within them, as well as for allowing that even the length of the arrays might vary….<\/p>\n
They are Unit Interface Variables<\/strong>.<\/p>\n
Or as some people like to call them:  Global<\/em> Variables<\/strong>.<\/p>\n
Anybody is free to add extra items to those arrays or change the values of any strings that might already be there.<\/p>\n
Fancy messing with a colleague’s Friday afternoon ?  Simply check-in this code somewhere in the initialization<\/strong> of a unit:<\/p>\n
\r\ninitialization\r\n  if not assigned(TrueBoolStrs) then\r\n    SetLength(TrueBoolStrs, 1);\r\n\r\n  if not assigned(FalseBoolStrs) then\r\n    SetLength(FalseBoolStrs, 1);\r\n\r\n  TrueBoolStrs[0]  := 'False';\r\n  FalseBoolStrs[0] := 'True';\r\n<\/pre>\n
Then sit back and wait for the hilarity to ensue.  (Of course your code review process will spoil your fun, but you get the point).  \ud83d\ude42<\/p>\n
More seriously, this of course (we must presume) to allow you to come up with your own alternative replacement strings for True<\/strong> and False<\/strong> for conversions.  Alternatives which you wish to use across the entirety of your application, in every nook and cranny where such conversions take place<\/em>.<\/p>\n
You can even define multiple strings from<\/em> which Booleans can then be converted (by StrToBool<\/strong> and TryStrToBool<\/strong>), although only the first<\/em> one in each array will be used when converting back the other way, as we have seen.<\/p>\n
Of course, to do that you need to check to see whether any RTL code might have already initialised those arrays and then just change or add the values you need, or you may need to initialise the arrays entirely, if the RTL has not yet initialised them.<\/p>\n
That VerifyBoolStrArrays<\/strong>() function is the one implementation detail that is private to the SysUtils<\/strong> function though unfortunately, so you’ll have to do all that the long way around.<\/p>\n
These complaints aside, initially this might seem quite useful, until you realise that this means that if you rely on this yourself, then you must also always be aware that every time you use some 3rd party library or framework there is a chance – however slim – that they too thought it would be a great idea to set up their own custom strings in those arrays and that their idea of what makes for really useful strings isn’t the same as yours.<\/p>\n
So not only is this convenient looking little utility method horrendously inefficient, all that overhead to make it possible necessarily involves exposing any consumer code to potential risk of side effects arising from sharing code.<\/p>\n
Yikes.<\/p>\n
 Retrospective \/ Legacy <\/h2>\n
Lest there be any confusion, this isn’t some newly introduced foible.  It has been this way – literally, identical in every respect – since at least Delphi 7 and current as of at least Seattle.<\/p>\n
 Conclusion <\/h2>\n
This one’s simple:  I think if you don’t mind I’ll stick to my Boolean-indexed arrays.  \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 5<\/span> minutes]<\/span><\/span> Jaap Van Goor was asking on FaceBook about some seemingly strange behaviour when obtaining string representations of Booleans using the Delphi RTL, which led me to revisit some familiar (and some not so familiar) old Delphi ground and take a look at the area involved in further detail.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[292,13],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-FG","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2597,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2597\/","url_meta":{"origin":2584,"position":0},"title":"(True = 1) and (True = ‘-1’) ?","date":"17 Mar 2017","format":false,"excerpt":"It has been observed that the Delphi documentation states that the constants True and False have the values 1 and 0 respectively, not the -1 and 0 that the default string conversions apply. This does actually make sense but also lays a trap for the unwary. True, True, Wherefore Art\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":507,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/507\/","url_meta":{"origin":2584,"position":1},"title":"Mind the Gap(s)","date":"14 Sep 2009","format":false,"excerpt":"This is what I love about Delphi. \u00a0After almost 15 years of Delphi'ing there's still new things to learn, and I don't just mean new features in the latest releases. \u00a0I mean, basic, fundamental things that have been there for years, just undiscovered (by me). \u00a0In this case the discovery\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1397,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1397\/","url_meta":{"origin":2584,"position":2},"title":"Qualified Enum Reference That Fails to Compile in XE4 (and rightly so)","date":"01 May 2013","format":false,"excerpt":"Running through some of my code last night, putting them through the new XE4 compiler, threw up a real oddity: Some code that used to compile just fine, which no longer compiles in XE4 and which should not have compiled before! It's an odd one, because the code previously compiled\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2624,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2624\/","url_meta":{"origin":2584,"position":3},"title":"Expressive If and Case …","date":"25 Apr 2017","format":false,"excerpt":"A quick post on a small but hugely useful little language feature in Oxygene... if expressions. Many people will be familiar with the so-called ternary operator. Delphi developers will also be aware that there is no direct equivalent in Delphi. In 'C' and other languages we can write a statement\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":3024,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3024\/","url_meta":{"origin":2584,"position":4},"title":"Scope Elevation: Creating A ‘Pseudo-Namespace’","date":"31 Oct 2019","format":false,"excerpt":"In my previous post I talked about how \"namespaces\" in Delphi really don't exist for any practical purposes normally associated with the concept. Having become familiar with the concept in other languages I found I was missing them, so I devised a way to obtain some of the benefits, despite\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/niklaus-wirth-edit.jpg?fit=934%2C362&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":1930,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1930\/","url_meta":{"origin":2584,"position":5},"title":"VCL Threading – Indeterminate Lifetimes","date":"18 Oct 2013","format":false,"excerpt":"Sometimes when you launch a thread you don't know when it will complete whatever processing it is tasked with. Sometimes you do. Sometimes it may never complete and will require that you expressly terminate it. Usually any given thread will have a lifecycle that is at least consistently one or\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2584"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2584"}],"version-history":[{"count":11,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2584\/revisions"}],"predecessor-version":[{"id":2596,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2584\/revisions\/2596"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}