StrCat versus String Concatenation Operator

[DAG_P6]

This may have been discussed when I wasn't paying close attention to the board. If so, please feel free to send me to the archives.

From a performance perspective, is there any reason to prefer one over the other, or are they more like different kinds of syntactic sugar, both implemented identically under the hood?

[td]

StrCat has a modest performance advantage over the concatenation operator.  However, for the vast majority of uses performance isn't a reason to prefer one over the other. Instead convenience is the more likely driver of preference.   

The reason for the performance difference has more to do with the interpreter's implementation than the  implementation of the concatenation functionality.

[td]

I have to retract part of the last post.  Out of curiosity I ran a couple of benchmarks and consistently got better times using the concatenation operator.  This runs counter to previous testing and suggest that the differences may be data dependent and may vary from system to system.

[DAG_P6]

Thanks much. That's pretty much what I expected was the case. Neither data dependency, nor that it might vary from system to system surprises me. The latter would be a given if the implementation depends on something along the lines of lstrcat() or RtlMemcpy(), both of which might be implemented differently in the underlying OS.

Out of curiosity, does either use something analogous to a .NET StringBuilder to avoid repeated trips to the heap? I would expect no less of you guys; indeed, it wouldn't surprise me to learn that you invented the StringBuilder. As I recall, it's fairly easy to make a MFC CString object behave like one.

[td]

WinBatch has its own custom string memory management system. 

[DAG_P6]

I know that, and I was attempting to pay you a compliment. I'm sure that yours is years ahead of the one the guys on the other side of Lake Washington put into the .NET Base Class Library. :)

[td]

I have had the good fortune of spending time communicating with a few MSFT senior software engineers over the years. Based on those experiences, I would expect the MSFT folks did a very good job of balancing all the requirements in the FCL's implementation.

Of course we might get a chance to find out for ourselves since MSFT is open sourcing the FCL and exposing the dotNet compiler APIs.

[DAG_P6]

I knew you had, and I have been very impressed with the speed and agility of the BCL. My point was that you guys probably had something akin to a StringBuilder long before .NET came into being.

[td]

Since Microsoft's FCL by definition runs on a virtual execution system, their solution would of necessity be quite different from the one used in WinBatch.

[DAG_P6]

Quite true, although the concept of a StringBuilder translates to other platforms and programming languages. Upon first reading the StringBuilder documentation, I though to myself that it's too bad that I didn't pursue the idea when it first occurred to me, many moons ago.

[td]

The CLI implements garbage collection so efficient memory management can be very complex.  WinBatch doesn't so optimizing memory usage is a bit less of a challenge.

When it comes to string memory management in a managed or native programming language, generics like C++ templates are a personal preference.  This is because this approach allows your string objects to have consistent syntax but you can select the memory manager that best suite the situation or you can even write your own memory manger to solve unusual problems.    The WIL interpreter implementation uses templates and several different memory mangers with memory manger selection depending on the lifetime of the internal string and several other considerations.   Of course, this internal string memory management is separate from the string memory management system used to handle strings as they are used in WIL scripts.   

[DAG_P6]

So! One size doesn't fit all, eh? ;)

[td]

Ironically, size is one of the virtues of generics.  You end up with highly reusable classes but only the parts you actually use in any given application or library get compiled into the final exe or dll. 

[DAG_P6]

The WIL interpreter implementation uses templates and several different memory mangers with memory manger selection depending on the lifetime of the internal string and several other considerations.   Of course, this internal string memory management is separate from the string memory management system used to handle strings as they are used in WIL scripts.   

I assume that you understood what I meant about one size not fitting all, right?

[td]

I assume that you understood what I meant about one size not fitting all, right?

Yes, of course, but apparently the use of the word 'ironically' wasn't sufficient to convey a play on words involving  a double entendre and one of the connotations of the phase "one size fits all."

[DAG_P6]

Yes, I missed the first word, thanks to that blasted comma. I apologize for the oversight.