Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Libraries and TheIDE: i18n, Unicode and Internationalization » Hack for MSC8 and "newline in constant" errors
Re: Hack for MSC8 and "newline in constant" errors [message #16883 is a reply to message #16858] Sat, 19 July 2008 09:47 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
FrankLin wrote on Thu, 17 July 2008 10:17

hello, all:

I am also new here and have the same problems.
My environment is as following:
OS:Windows Vista (Traditional Chinese version)
Compiler: minGW, MSC8

After some hacking, I found something and it seems the point.
If we used MSC8 to compile upp, we would encounter an error message like this:
C:\Users\FrankLin\ubin\upp\uppsrc\Core/Core.t(37) : error C2001: newline in constant

Core.t is the UTF-8 format and Windows was used to add "EF BB BF" called BOM to every UTF-8 files in order to identify UTF-8 file. The problem is there is no BOM in Core.t.

When I transfered the original Core.t to the new that Windows can identify, the MSC8 can know the format of this file and compile well.

Although the compilation works, there is another warning message like this:
C:\Users\FrankLin\ubin\upp\uppsrc\Core/Core.t(957) : warning C4566: character represented by universal-character-name '\u00E9' cannot be represented in the current code page (950)
This warning is due to the macro itself. For example:in Core.t
we have
zhCN("星期日")

and after preprocessor, we got in some where
const char *text = "星期日" 

So the warning seems reasonable.

There is another problem when I added BOM to both Core.t and CtrlLib.t. The MSC8 can work but minGW compiled failed....

It seems minGW didnt accept BOM added UTF-8 files.

any suggestion is appreciated.


Well, but that is only partial solution...

What we really need here is that the compiler stops checking the content of strings... which should be forced by #pragma setlocale("C") but for whatever reason, it does not work...

(Maybe somebody could check with MSC9).

Mirek
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: version 1579, CharSet.h, CHARSET_KOI8_R redefined and Ctrllib.t, fail to compiling with MSVC9
Next Topic: Adding new .scd spelling dictionary
Goto Forum:
  


Current Time: Wed May 22 03:47:18 CEST 2024

Total time taken to generate the page: 0.01842 seconds