AnsiString oddities

[EddieDee 0]

I've been using C++ Builder since v1, and until Windows 7 broke my copy of C++ Builder 3 I used it regularly.

 

So I recently discovered Embarcadero has the community edition of C++ Builder, and so I downloaded it. Unfortunately it is a convoluted mess to me, as I HATE using unicode strings! Give me the old days! :-)

 

But I've managed to convert most of my code over now, but ran into an odd problem. I have a few lines of code that don't seem to be working. Here's an example:

 

AnsiString s;
s = Form1->InputString;
s += L" - Some Extra Text.";

When I set a breakpoint on the next line of code, then examine s, I see:

> s { ???? }

instead of what should be there! In this case, InputString is an AnsiString that contains the text "Start Here". If I examine that variable I see:

 

> InputString { "Start Here" }

So, shouldn't I see:

> InputString { "Start Here - Some Extra Text" }

when I examine s?

 

This makes no sense to me! Especially when I move the breakpoint to the concatenation line and examine s before the "Extra Text" is added. As it still shows { ???? } when I evaluate it!

 

Any ideas?

[Attila Kovacs 629]

for curiosity's sake, is there any compiler hint on that concat?

[corneliusdavid 214]

It's been a while since I used C++ but I think you might need to use a StringBuilder class and call methods to concatenate string.

[Fraser 2]

There is something not right with the integrated debugger.  If you step into the concatenation and out again you will see what you expect.  Is it a mistake that you assign a wide character string literal to a char based string type?

[Remy Lebeau 1394]

21 hours ago, EddieDee said:

I've been using C++ Builder since v1, and until Windows 7 broke my copy of C++ Builder 3 I used it regularly.

Don't feel bad.  Until about a year ago, I was still regularly using C+++Builder 6 at my day job.

Quote

 

AnsiString s;
s = Form1->InputString;
s += L" - Some Extra Text.";

Why are you concatenating a WIDE string literal to an ANSI string?  You should drop the 'L' prefix, it doesn't really belong there. AnsiString doesn't have an operator+= that takes a Unicode string as input, only another AnsiString.  So you are actually invoking the AnsiString constructor that accepts a Unicode string, and that is forcing a Unicode->ANSI data conversion at runtime, which you don't need.

Quote

When I set a breakpoint on the next line of code, then examine s, I see:

> s { ???? }

instead of what should be there!

The code looks fine, provided that the Form1 pointer is valid to begin with, otherwise the code would have undefined behavior.

Quote

So, shouldn't I see:

> InputString { "Start Here - Some Extra Text" }

when I examine s?

Yes, you should, provided everything is valid.  Have you tried displaying the AnsiString anywhere other than in a debug inspector?  Have you tried showing it in your app's UI?  Or in a popup MessageBox?  Or save it to a file? Anything?

Quote

This makes no sense to me!

That is what the debugger is meant for.  Step through the code at runtime line by line, and actually step into the internal logic of the assignment and concatenation operations to make sure they are doing what you are expecting.

Quote

Especially when I move the breakpoint to the concatenation line and examine s before the "Extra Text" is added. As it still shows { ???? } when I evaluate it!

The only way I could imagine that happening is if either the Form1 pointer is invalid during the assignment, or if the debugger is broken.  Which do you think is more likely?

Edited December 20, 2021 by Remy Lebeau

[Remy Lebeau 1394]

17 hours ago, corneliusdavid said:

It's been a while since I used C++ but I think you might need to use a StringBuilder class and call methods to concatenate string.

All string classes in C++Builder - the RTL's (Ansi|Unicode|Wide)String classes, the Standard Library's std::(w|u8|u16|u32)string classes, etc - have concatenation methods built-in.  The main reason for using a StringBuilder is memory management (being able to preallocate a buffer and then performing multiple concatenations into it), and that really only applies to RTL strings, as Standard Library strings have a reserve() method for that same purpose.  Also, the standard C++ alternative to a StringBuilder is the std::(w)istringstream classes.

[corneliusdavid 214]

@Remy Lebeau Thanks for the correction and explanation.

[EddieDee 0]

While digging further into this today, I discovered that if I switched the compiler to the 'classic' bcc32 compiler the debugger issue went away and I was able to see the evaluation of the variable without any issues. So it seems that this is a "feature" of the non-classic compiler.

Quote

Why are you concatenating a WIDE string literal to an ANSI string?  You should drop the 'L' prefix, it doesn't really belong there.

True. And I did try it both with and without a wide literal string. I got the same results both ways.

[Remy Lebeau 1394]

12 hours ago, EddieDee said:

While digging further into this today, I discovered that if I switched the compiler to the 'classic' bcc32 compiler the debugger issue went away and I was able to see the evaluation of the variable without any issues. So it seems that this is a "feature" of the non-classic compiler.

Honestly, I have yet to try any of the Clang compilers at all, and while I would love to be able to use newer C++ language features in my code, this issue just reaffirms why I have no desire to EVER use the Clang compilers.  They are just not supported properly in the IDE or the libraries.  Too many problems that are "solved" by using the classic compiler instead.

[EddieDee 0]

4 hours ago, Remy Lebeau said:

Honestly, I have yet to try any of the Clang compilers at all, and while I would love to be able to use newer C++ language features in my code, this issue just reaffirms why I have no desire to EVER use the Clang compilers.  They are just not supported properly in the IDE or the libraries.  Too many problems that are "solved" by using the classic compiler instead.

That's what I'm quickly finding out! All that the Clang compilers have done is forced me to modify code that really never needed modifying! I never realized there was a way to switch it back to the "classic" world until yesterday.

 

But it's still light years better than using Visual Studio! :-)