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
Hack for MSC8 and "newline in constant" errors [message #10439] Mon, 09 July 2007 13:43 Go to next message
kfeng is currently offline  kfeng
Messages: 18
Registered: July 2007
Location: Tokyo, Japan
Promising Member
Hi,

I'm new to upp, and I almost gave it up after two days, because it wouldn't compile under MSC8 under WinXP...

...until I found a hacky work-around... ...In Core/Language/t.h, search for TFILE and just comment out the line like this:

// #include TFILE

or wrap it with an #ifndef:

#ifndef PLATFORM_WIN32
#include TFILE
#endif

Of course, this is ugly - but given the choice of not being able to compile at all and losing Localization support, I volunteer to take the lesser evil.

I hope some expert developers in upp can come up with a more graceful solution than this, but looking through the threads, I'm not the first one to notice this problem...

- Ken

------------------------------------------------------------ ---

F:\upp\uppsrc\CtrlLib/CtrlLib.t : warning C4819: The file contains a character that cannot be represented
in the current code page (932). Save the file in Unicode format to prevent data loss
F:\upp\uppsrc\CtrlLib/CtrlLib.t(29) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(41) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(43) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(53) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(65) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(76) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(77) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(89) : error C2001: newline in constant
F:\upp\uppsrc\CtrlLib/CtrlLib.t(91) : error C2001: newline in constant
Re: Hack for MSC8 and "newline in constant" errors [message #10440 is a reply to message #10439] Mon, 09 July 2007 13:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
So far, the only known solution is to use setup the windows to be "english" (it is really weird, but this global setting affects a way how MSC deals with string literals. The problem here seems to be that in Chinesse, the compiler expects to see multibyte characters in literals and for whatever reason, they have decided whether these multibyte sequences are correct, even when they do not do anything with them...).

Mirek
Re: Hack for MSC8 and "newline in constant" errors [message #10441 is a reply to message #10440] Mon, 09 July 2007 14:27 Go to previous messageGo to next message
kfeng is currently offline  kfeng
Messages: 18
Registered: July 2007
Location: Tokyo, Japan
Promising Member
Actually, it's not just Chinese. I suspect any CJK-based Windows system compiling under MSC8 will have problems (MSC71 seems to be ok). At home, I have a Japanese based WinXP and at work, a Japanese based Windows 2000 machine - both fail to compile with the same errors under MSC8.

It messes too many things up to switch to English just to compile upp so I just comment out the Localization.

The percentage of new users who are configured like this is probably not high, but it is definitely a turn-off for new developers. If there is a way to "just get it to build" (using Macros, even?), I would recommend committing it into the release until MS fixes MSC8... ...or at least put it in some "Known Problems" or "Readme" file so developers can use a hack-around.

I don't mean to be nit-picking about this as it looks like a Microsoft bug, but it would be a pity to lose new developers due to a glitch like this... ...the overall upp system is amazingly clean and intuitive (including the IDE - take some getting used to, but it's actually quite good), and I'm discovering new and interesting implementations of the upp GUI every day.

Keep up the good work!

- Ken

[Updated on: Mon, 09 July 2007 14:32]

Report message to a moderator

Re: Hack for MSC8 and "newline in constant" errors [message #10443 is a reply to message #10441] Mon, 09 July 2007 16:11 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Actually, I would be happy to see any progress here.

In fact, I believe that

#pragma setlocale("C")

(or something like this, not 100% sure at the moment)

should solve it, that is why we put it to all .t files. But I am now not sure when this was in fact introduced, perhaps check you have it there...

Mirek
Re: Hack for MSC8 and "newline in constant" errors [message #16858 is a reply to message #10443] Thu, 17 July 2008 16:17 Go to previous messageGo to next message
FrankLin is currently offline  FrankLin
Messages: 1
Registered: July 2008
Location: Taiwan
Junior Member
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.
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 next message
mirek is currently offline  mirek
Messages: 13975
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
Re: Hack for MSC8 and "newline in constant" errors [message #23397 is a reply to message #16883] Fri, 16 October 2009 18:46 Go to previous messageGo to next message
yoco is currently offline  yoco
Messages: 25
Registered: June 2006
Location: Taiwan
Promising Member
I tested with MSVC9, and, you know, MS sux Razz The
#progma setlocale ("C")

still don't work.
Re: Hack for MSC8 and "newline in constant" errors [message #23425 is a reply to message #23397] Sun, 18 October 2009 21:30 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
yoco wrote on Fri, 16 October 2009 12:46

I tested with MSVC9, and, you know, MS sux Razz The
#progma setlocale ("C")

still don't work.


Yep, they just ignore the thing....

Seriously, the only way out I can see is too monstrous - make it part of build process and actually export all .t files into something else.

I am quite sure I do not really want to follow this path. It would break the code too (you would have to include something else than .t file).

Mirek
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: Thu Mar 28 13:00:59 CET 2024

Total time taken to generate the page: 0.01100 seconds