Should I switch from Borland C++ Builder 6.0 to Embarcadero C++??

[HuntsvilleRob]

Hello. The subject says it all. Is it worth it to switch to the latest version of Embarcadero C++ Builder? Are there many more and much better tools or is it just the same? Thanks! -Rob

 

[2ffat]

The new Embarcadero tools are more compliant to the new C++ standard, they have tools for the new Windows 7 look and feel, and they allow you to use the new wide strings (say good-bye to AnsiStrings and hello to UnicodeStrings).



James P. Cottingham
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[smays]

I know I am a little late responding to this thread. I have 2009, of which I am very fond and I would really like to upgrade to XE2! So, 2ffat, do 2010 and later versions (XE) no longer support AnsiString at all? 2009 is "Unicode[String]-all-the-way", but still gives full support to AnsiString, which is vital for any kind backwards compatibility.

Steve.

 

[2ffat]

AnsiString is supported. There is one caveat. In the older version, e.g., BCB6, String was equivalent to AnsiString. In 10, it is equivalent to UnicodeString. The good news is all the methods you enjoyed with AnsiString, you also have with UnicodeString. For example:

AnsiString MyStrng = "something";
AnsiString NewStrng = MyStrng.SubString(1,4); // some

UnicodeString MyStrng = "something";
UnicodeString NewStrng = MyStrng.SubString(1,4); // some



James P. Cottingham
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[smays]

You forgot the most important feature of AnsiString (versus UnicodeString), the c_str() member function of AnsiString still means something to legacy C APIs!

Steve.

 

[2ffat]

This is how Unicode's c_str() works:

Returns a pointer to the underlying string data as const wchar_t*.

c_str returns a wchar_t pointer to the location in memory where the value of the UnicodeString object is stored. If the UnicodeString is unassigned, c_str returns a wchar_t pointer to the empty string (“”).

Usually, the value returned by c_str points to the internal character array referenced by the data function. This pointer is valid until the UnicodeString is next modified (for example, when the SetLength method is called or the UnicodeString goes out of scope). However, if the internal array is NULL, c_str returns a wchar_t pointer to the empty string (“”).

The c_str method is intended primarily for reading the value of the UnicodeString. To modify the UnicodeString’s value, use the [] operator or UnicodeString methods such as Insert and Delete.

James P. Cottingham
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[smays]

I guess my point is, if one is using a C API that is expecting to be passed a pointer to an 8-bit wide char array, c_str(), as implemented by the UnicodeString class (16-bit wide whar_t) cannot be used. Whereas c_str() as implemented by AnsiString returns a point to an 8-bit wide char array. Therefore, if one is using a 'legacy' C API, such as much of the Win32 API, especially for serial communication, UnicodeString cannot be used directly.

I always copy the string data to an AnsiString to then be passed to the Win32 API. I do the vast majority of my work with UnicodeString until I have to pass data to a legacy C API function call at which point I copy the data from a UnicodeString to an AnsiString.

Steve.