Support for Windows1252 character set?

[izovt]

In our code we use the Windows1252 character set.
All characters in this set are supported by the Visual Studio C++ compiler. These characters are used in our code and read from and written to XML files.

When using the Intel C++ compiler (from within Visual Studio 2008) some of our testcases fail. It seems that from the Windows1252 character set some characters are not supported. In the debugger and in the output XML files these characters are shown as 'squares'.

see http://en.wikipedia.org/wiki/Windows-1252
Characters in the range 0x80 to 0x9F seems to be unsupported.

Can somebody tell if there is a workaround for this problem?
The version of the Intel C++ compiler used is: 11.0.750.2008

Regards,
Izo van Thiel.

[TimP]

Unless you get lucky and find someone with experience on a similar problem, a (preferably small) test case would be needed. For example, it might be some specific library function which fails; how are we to know which functions you require?
A problem report on your support account at https://premier.intel.com would be appropriate, if you don't want to discuss it here.

[aazue]

Hi
Your problem is probably you having one side in 1252 and the other utf8
(only utf8 can result same problem)
best regards

[izovt]

I will try to add some small example code tomorrow (local time). Good remark. I will probably also create a problem report, but the person with the account details is not in these days.

What I was actually hoping for was that someone, probably an Intel engineer or alike, could tell if the Intel C++ compiler supports the Windows1252 character set. And ifso, if it is possible to change the used character set by some compiler option.

In Code::Blocks, using the GNU GCC Compiler, I can change the character set by adding
-finput-charset=windows-1252 as a compiler option.

The actual problem is not that code crashes, but our testcases compare its output with expected output. When these outputs do not match the testcase fails. And when our project is build with the Intel C++ compiler the testcases that expect one or more of the windows1252 characters in the 80-9F range will fail.

[izovt]

Had a look at that but could not yet figure that out correctly.

Using the Visual Studio C++ default compiler though the same testcases are OK, no problem with the characters in the mentioned character range.

[aazue]

Hi
If i have submit probably problem UTF8 is i have experience this problem approximately similar situation and resolved in this sens.
best regards

[izovt]

Guys,

I have made a very tiny project which shows the problem.

int _tmain(int argc, _TCHAR* argv[])
{
wstring Text = L"Text: ?\\_"";
return 0;
}

With VisualStudio 2008 (default compiler) debugger Text will be the correct string.
With VisualStudio 2008 (Intel C++ compiler) debugger Text will be "Text: ?\_"".
Actually in the debugger three squares are displayed, not 0080, 0086 and 008C.

A small project is attached. Any ideas are very welcome.

Regards, Izo.

[JenniferJ · Accepted solution]

Thetestcase helps.

After I saved the testing.cpp to "unicode - codepage 1200", it worked for me. To do that, click on menu "File -> save as", the select "Save with Encoding".

Jennifer

[izovt]

Jennifer, it sounded promising, until I tried it in my environment. The following was the build output:

1>------ Rebuild All started: Project: Testing, Configuration: Debug Win32 ------
1>Deleting intermediate files and output files for project 'Testing', configuration 'Debug|Win32'.
1>Compiling with Intel C++ 11.0.066 [IA-32]... (Intel C++ Environment)
1>Testing.cpp
1>Catastrophic error: UTF-16 (a.k.a. "Unicode") source files are not supported
1>
1>stdafx.cpp
1>compilation aborted for .\Testing.cpp (code 4)
1>Build log was saved at "file://D:\nlivt\Testing\Testing\Debug\BuildLog.htm"
1>Testing - 0 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Is this a version issue?


Izo.

[JenniferJ]

Yes, you need the 11.1 compiler. Try the eval. It's 11.1 latest.

Jennifer

[aazue]

Hi
As confirm that problem is really UTF8 ENCODE/DECODE ICC side
If i remember ? you can use Verdana font, with can be resolve this problem sometimes,
but not always true.
Best regards

[izovt]

Thank you very much, Jennifer!
That does the trick. Now I only hope that source safe can understand the changed file :-)

Regards,
Izo.