Delphi XE4 immutable strings -


with delphi xe4 ios platform new string type introduced: immutable 0 based strings. far delphi had copy on write mutable strings. question is, mean future programming? there advantages of 1 string type on other? pitfalls need take care of when switching new string type (other obvious 0 vs 1 base)?

according marco cantù's whitepaper, string data type in xe4 ios target not in fact immutable, although seems contradict himself.

he says:

in new delphi llvm-based compiler, there 1 string type, representing unicode strings (utf16), , mapped current string type in delphi xe3 (an alias unicodestring type on windows compiler). however, new string type uses different memory management model. string type still reference counted, immutable, means cannot modify string contents once constructed.

but goes on say:

in other words strings unicode-based, soon-to-become immutable, , reference-counted.

and also:

where things start change, however, when modify existing string, not replacing new value (in case brand new string) when modify 1 of elements, shown in line of code (and in previous section, introduced topic):

str1 [3] := 'x'; 

all delphi compilers use copy-on-write semantics: if string modify has more 1 reference, first copied (adjusting reference counts of various strings involved required) , later modified.

the new compiler similar classic one. implements copy-on-write mechanism, unless there single reference string, in case string gets modified in place. example, consider following code, outputs in-memory location of actual string.

and shows picture of ios device mutating strings.

and in official documentation have:

strings immutable (constant), cannot index string array , manipulate characters in string. if attempt modify string, delphi mobile compilers might emit message w1068 modifying strings in place may not supported in future (delphi). can specify whether message x1068 emitted warning or error. in hints , warnings page, set warning "modifying strings in-place...." "true" or "error".

so interpret meaning xe4 release of ios compiler still has mutable strings. developers don't want mutate strings more , telling strings immutable on mobile compilers. appear still mutable. go figure!


however, have been served notice in future release, string may become immutable.

you can prepare future release setting

{$warn immutable_strings warn} 

which give idea of impact of change. if want buckle , stop mutating strings, can this:

{$warn immutable_strings error} 

once you'll need convert code accesses individual string elements. suspect you'll surprised how little such code there is. compiled 600,000 lines of code , saw 120 instances of warning. , of in third party units. i've seen quite stir change, don't believe code mutates strings. in overwhelming majority of cases strings built concatenation, or calls functions format. code not affected this.

i don't think there great pitfalls. can use {$warn immutable_strings ...} let compiler guide through process. code mutates strings should converted use tstringbuilder.

as benefits of immutability, refer why .net string immutable?

if using traditional windows or osx compilers see no compelling reason change. ios compiler brand new. change immutable strings has been floated, may never happen. may happen on mobile compilers , never on traditional compilers. right now, sit tight, , wait see how plays out.


Popular posts from this blog

How to calculate SNR of signals in MATLAB? -

c# - Attempting to upload to FTP: System.Net.WebException: System error -

ios - UISlider customization: how to properly add shadow to custom knob image -