If you're using Tnt and you're converting between code pages already, then yes, switching to Delphi 2010 will cause you extra work because you'll need to remove code for things that Delphi now handles intrinsically. Ultimately, your code will be simpler, but it will be a hassle to get it there in the meantime. SizeOf, Length, and FillChar are very basic concepts that you, as a professional software developer, owe to yourself to understand.Be cognizant of whether you're dealing with character data or non-character data, and when dealing with the latter, don't use character-related types.
You've got TBytes; use it. Don't use strings as byte buffers. When you want to know how many bytes you have, use SizeOf; when you want to know how many "things" you have, use Length.
Generally avoid FillChar; you probably don't need it as much as you use it today anyway. Since the "char" that things are filled with is almost always zero anyway, you might consider using ZeroMemory instead.It has fewer parameters and is just as fast as FillChar, especially since Delphi supports function inlining. The compiler warns you when converting from AnsiString to UnicodeString because it's not a simple string assignment but rather a conversion, guaranteed to allocate more memory and copy everything one character at a time.
It's a performance warning, not a data-loss warning. Conversions in the opposite direction are both (even when assigning to Utf8String, which technically will never lose data from a UnicodeString, if it's filled only with valid Unicode characters). The best way to avoid the warning is to not use AnsiString in the first place.
Use plain old String except for code that really does need to know what code page to encode things as. I don't think the "retest" argument is very strong. The library code especially should have unit tests that you've been running every time you recompiled.
Retesting is something you do several times a day; there's no special effort involved unless something goes wrong.
Assigning an AnsiString to a UnicodeString CAN cause data loss! That is why the compiler issues a warning for it. It is not a performance warning, it really is a data warning.
Assigning a UnicodeString to a UTF8String, on the other hand, will NOT cause any data loss, as UTF-8 is a loss-less Unicode encoding by design, and no compiler warning is reported for it. – Remy Lebeau - TeamB Dec 14 '09 at 20:16 What characters storable in an AnsiString are not represented in Unicode, and what character sets are they in? – Rob Kennedy Dec 14 '09 at 20:48 Remy?
Rob's got a point here. Care to elaborate on what losses upconversion from 8 bit AnsiString UP to UnicodeString could ever cause? Because the only reason I thought the warning was in there, was to make you think "Why do I have this AnsiString here, and am I not wasting memory and CPU time with all these implicit upconversions?" – Warren P Feb 10 '10 at 23:50 I wish I could upvote twice for the "retest" point #4 above.
– Warren P Jul 30 '10 at 13:22.
Conversion Unicode string to specified code page with only Delphi: Simpler than ever. Thanks to the String class ability to create a string of a desired codepage, and convert cleanly from one codepage to another. FillChar is bytes, not characters, name is now unfortunate.
Not that confusing really. That warning is there to make you think, which it did. Job done.
Oh yes. But that retesting and re-reading has been the biggest benefit for me. I have migrated all my projects to Delphi 2009/2010 and found the benefits included: A.
A thorough re-reading of my code brought many ways I needed to clean it up (because it's a bloated old mass of accidents and incremental code-sludge, like most RAD/delphi projects end up), few of which are purely unicode or port related, but all of which made the products better for being forced through the changes. B. A cleaner world, with fewer third-party components.
Dropping TNT, and a dozen or two third party components will make your project smaller, more orthogonal and easier to support. C. There's no reason in porting to make it one way.
None of my project ports are actually "moved" permanently into Delphi 2009/2010. They all build in both worlds just fine. I use the type UnicodeString widely in all my code wherever I need it, and I make a typedef to WideString, when compiling on Delphi 2007 or older versions.D.
The delphi 2010 ide works great on Windows Vista and Windows 7, and the language is a joy to work with. Delphi 2009 and 2010 don't crash, which Delphi 2007 and Delphi 7 often do for me. If you don't need to support Vista and Win7, and you're 100% happy and glitch-free running TNT components, and your app doesn't make you money, then leave it where it is.
If it makes you money, invest your time, and you will soon see the rewards. Delphi 2010 and 2009 are easily the best delphi versions ever, and the only major headache that remains is that the documentation has remained below the quality of Delphi 7 ever since they moved off WinHelp format help files.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.