std :: ostringstream с float ведет себя иначе с компилятором Embarcadero CLANG.

Я столкнулся с очень странным поведением Embarcadero C ++ Builder при использовании компилятора CLANG.

Пример очень простой:

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() );
}

Пока код компилируется классическим компилятором Borlands, он выводит именно то, что я ожидал:

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

Однако как только я переключаюсь на компилятор CLANG (bcc32c) (сняв флажок использовать классический компилятор в диалоговом окне настроек), я получаю следующий результат:

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

Изменить: не обращайте внимания на проблему с std :: string - важно ложное число с плавающей запятой.

(Мало того, что числа с плавающей запятой дробятся, также, похоже, возникает проблема с интерпретацией обычных std :: string.)

В чем проблема с bcc32c и как с этим справиться?

Я использую Embarcadero C ++ Builder 10.0 (Сиэтл) для целевой платформы WIN32.

Спасибо


person Herwig    schedule 01.12.2020    source источник
comment
Это может быть проблема с кодировкой, например. UTF-8 против ??? (ANSI или что-то еще). Символы в ваших строковых литералах имеют кодировку вашего исходного кода. Если компилятор использует другую кодировку для вывода, тогда ... Не уверен, какое это имеет отношение к floats, но это объясняет N°3.   -  person Scheff's Cat    schedule 01.12.2020
comment
oss << '\r' << '\n'; используйте только oss << '\n';. \n будет автоматически преобразован в правильный символ новой строки для каждой платформы средой выполнения C. И попробуйте использовать кодировку UTF-8 только для новых компиляторов. Вероятно, Embarcadero настолько стар, что использует кодовые страницы ANSI.   -  person phuclv    schedule 01.12.2020
comment
Подробнее о N°3: ° имеет код 176 ('\xb0') в Windows-1252, но представляет собой двухбайтовую последовательность в UTF-8: "\xc2\xb0". Теперь снова эти два байта в Windows-1252: °. Итак, я предполагаю, что ваш строковый литерал в исходном коде закодирован в UTF-8, но вывод выполняется с его декодированием как Windows-1252.   -  person Scheff's Cat    schedule 01.12.2020
comment
Я получаю N�1: 1234 N�2: 12.34 N°3: 4567 N°4: 45.67 с G ++ в Windows. (Хотя без этой древней __fastcall штуки, но это ничего не должно изменить)   -  person nada    schedule 01.12.2020
comment
Правильные вопросы: в какой кодировке находится ваш исходный файл? В какой кодировке используется консоль (или что-то еще), на которую вы выводите? Как заставить обоих «сотрудничать»? Может быть, ICU или Boost UTF - это ответ здесь?   -  person nada    schedule 01.12.2020
comment
Проблему с UTF-8 можно проигнорировать. Главный вопрос по поплавку.   -  person Herwig    schedule 01.12.2020


Ответы (1)


Сразу после того, как я написал свой пост, я наткнулся на эту статью на сайте embarcadero:

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

Кажется, это хорошо известная ошибка в Embarcadero C ++ Builder, которая уже была исправлена ​​в его выпуске Update 1.

К сожалению, у меня нет доступа к этому исправлению, потому что я приобрел только версию Enterprise, но не заплатил дополнительную плату за пакет подписки, что является обязательным, если вы хотите исправить их ошибки.

person Herwig    schedule 01.12.2020
comment
Менеджер по продукту C ++ Builder здесь. Будет сложно помочь вам с проблемой подписки, возникшей более пяти лет назад, но, пожалуйста, напишите мне ([email protected]). Необычно совершать покупки без годовой поддержки / обновлений новой версии, где вы ' Я буду исправлять все ошибки в течение года, и, может быть, мы сможем увидеть, что произошло, или я смогу помочь другим способом. - person David; 07.12.2020