views:

534

answers:

3

As far as I know, strings are immutable in Delphi. I kind of understand that means if you do:

string1 := 'Hello';
string1 := string1 + " World";

first string is destroyed and you get a reference to a new string "Hello World".

But what happens if you have the same string in different places around your code?

I have a string hash assigned for identifying several variables, so for example a "change" is identified by a hash value of the properties of that change. That way it's easy for me to check to "changes" for equality.

Now, each hash is computed separately (not all the properties are taken into account so that to separate instances can be equal even if they differ on some values).

The question is, how does Delphi handles those strings? If I compute to separate hashes to the same 10 byte length string, what do I get? Two memory blocks of 10 bytes or two references to the same memory block?

Clarification: A change is composed by some properties read from the database and is generated by an individual thread. The TChange class has a GetHash method that computes a hash based on some of the values (but not all) resulting on a string. Now, other threads receive the Change and have to compare it to previously processed changes so that they don't process the same (logical) change. Hence the hash and, as they have separate instances, two different strings are computed. I'm trying to determine if it'd be a real improvement to change from string to something like a 128 bit hash or it'll be just wasting my time.

Edit: Version of Delphi is Delphi 7.0

A: 

The Delphi version may be important to know. The good old Delphi BCL handles strings as copy-on-write, which basically means that a new instance is created when something in the string is changed. So yes, they are more or less immutable.

Lucero
The thing is ... What if I generate the same string from two different sections of code? That's not copy on write...
Jorge Córdoba
BCL? I think you mean RTL. (You didn't mean VCL; the VCL doesn't control how strings work at all.)
Rob Kennedy
@Jorge: Generating a string with the same contents does not make it the same reference. But this has nothing to do with immutability.@Rob: Well, BCL stands for Base Class Library, the RTL is one of those beasts... ;)
Lucero
+15  A: 

Delphi strings are copy on write. If you modify a string (without using pointer tricks or similar techniques to fool the compiler), no other references to the same string will be affected.

Delphi strings are not interned. If you create the same string from two separate sections of code, they will not share the same backing store - the same data will be stored twice.

Barry Kelly
I once had a problem with string manipulations in a DLL, and after a long search I discovered that IsMultiThread was set to false. It's declared in System.pas and is used when modifying string reference counting and storage. Setting it to true in my initialization section solved my problem.
Stijn Sanders
Stijn - the reference-counting mechanism uses bus-locking increment and decrement instructions to be safe for multithreading. These are slower than normal inc and dec though. IsMultiThread is set by creating a thread from within Delphi. Of course, if you create a thread outside Delphi, or using the raw underlying API, it won't know.
Barry Kelly
+1  A: 

As others have said, Delphi strings are not generally immutable. Here are a few references on strings in Delphi.

http://blog.marcocantu.com/blog/delphi_super_duper_strings.html

http://conferences.codegear.com/he/article/32120

http://www.codexterity.com/delphistrings.htm

Herbert Sitz