0

I am facing a very odd behaviour of the Embarcadero C++ Builder when using the CLANG compiler.

The example is very simple:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
    std::wostringstream woss;

    woss << std::wstring(L"N°1: ") << (int) 1234;
    woss << '\r' << '\n';
    woss << std::wstring(L"N°2: ") << (float) 12.34;

    Memo1->Lines->Add( woss.str().c_str() );

    std::ostringstream oss;

    oss << std::string("N°3: ") << (int) 4567;
    oss << '\r' << '\n';
    oss << std::string("N°4: ") << (float) 45.67;

    Memo1->Lines->Add( oss.str().c_str() );
}

As long as the code is compiled with Borlands classic compiler, it prints exactly what I am expecting:

  • N°1: 1234
  • N°2: 12.34
  • N°3: 4567
  • N°4: 45.67

However, as soon as I switch to the CLANG compiler (bcc32c) (by unchecking "use classic compiler" in the settings dialog) I get the following result:

  • N°1: 1234
  • N°2: -0
  • N°3: 4567
  • N°4: -0

Edit: please ignore the issue with the std::string - the important thing is the false floating point number.

(Not only that the float numbers get crushed, there seems also to be an issue with the interpretation of regular std::string's.)

What is the problem with bcc32c and how can I handle this?

I am using Embarcadero C++ Builder 10.0 (Seattle) for the WIN32 target platform.

thank you

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Herwig
  • 316
  • 1
  • 17
  • It might be an issue with the encoding e.g. UTF-8 vs. ??? (ANSI or whatever). The characters in your string literals have the encoding of your source code. If the compiler uses a different encoding for you output then... Not sure what this has to do with the `float`s but it would explain the `N°3`. – Scheff's Cat Dec 01 '20 at 10:49
  • `oss << '\r' << '\n';` use `oss << '\n';` only. The `\n` will automatically be converted to the correct new line character for each platform by the C runtime. And try to use UTF-8 encoding only for new compilers. Probably Embarcadero is so old that it uses "ANSI" code pages – phuclv Dec 01 '20 at 10:59
  • 1
    About `N°3` in detail: `°` has the code 176 (`'\xb0'`) in [Windows-1252](https://en.wikipedia.org/wiki/Windows-1252) but is a two byte sequence in [UTF-8](https://www.utf8-chartable.de/): `"\xc2\xb0"`. Now, these two bytes in Windows-1252 again: `°`. So, I assume your string literal in source code is encoded in UTF-8 but the output is done decoding it as Windows-1252. – Scheff's Cat Dec 01 '20 at 11:03
  • I get `N�1: 1234 N�2: 12.34 N°3: 4567 N°4: 45.67` with G++ in Windows. (Although without that ancient `__fastcall` thingy, but this shouldn't change anything) – nada Dec 01 '20 at 11:07
  • 1
    The correct questions to ask are: What encoding is your sourcefile in? What encoding is the console (or whatever) you're outputting to using? How do you get both to 'cooperate'? Maybe ICU or boost's UTF stuff is the answer here? – nada Dec 01 '20 at 11:11
  • The issue with UTF-8 can be ignored. The main question is about the float. – Herwig Dec 01 '20 at 11:34

1 Answers1

0

Just right after I have written my post I stumbled accross this article on the embarcadero website:

https://quality.embarcadero.com/browse/RSP-12643

It seems to be a well known bug in Embarcadero C++ Builder which has already been fixed in its Update 1 release.

Unfortunately I have no access to this Bugfix because I have "only" purchased the Enterprise Version, but did not pay the extra fee for the subscription pack, which is mandatory when you want to have their bugs fixed.

Herwig
  • 316
  • 1
  • 17
  • 3
    C++Builder product manager here. It's going to be difficult helping you with a subscription issue from over five years ago, but please feel free to email me (david.millington@embarcadero.com.) It's unusual to have purchased without a year's support / new version updates where you'd get all bugfixes through the year, and maybe we can see what happened or I can help some other way. – David Dec 07 '20 at 11:28