<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width.<BR> <BR> <BR>It might as well be UINT32 or UInt32?<BR> <BR> <BR>In C++, std::string is std::basic_string<char>, std::wstring = std::basic_string<wchar_t>.<BR>Could/should we use generics similarly?<BR> <BR> <BR>CharText, WIDECHAR=UINT16, WideCharText, UInt32Text?<BR> <BR> <BR>There is the problem of text literals.<BR>The current "text" can change between "char" and "widechar".<BR> <BR> <BR>Can "widechar" vary per-target?<BR>In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it?<BR>(I just checked -- Linux/amd64 does have 32bit wchar_t).<BR> <BR> <BR>It is a thorny issue though, there are pluses and minuse either way.<BR>An alternative would be to have WIDECHAR be the same for all targets.<BR><br> <BR> - Jay<br> <BR><div>> Date: Sun, 15 Dec 2013 09:40:26 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] cm3 does not support Scan.LongInt<br>> <br>> <br>> <br>> On 12/14/2013 04:45 AM, Elmar Stellnberger wrote:<br>> > Converting my automaton simulator I have just discovered that there is no Scan.LongInt though there is a Fmt.LongInt.<br>> > Would anyone mind this to fix in the main trunk?<br>> ><br>> > Also I hope that there will be a ready-to-use GUI as soon as I will come into implementing the GUI part of the simulator.<br>> > I had a superfluous look at Modula-3 Qt but I am not yet sure on how the signal concept was mapped onto Modula-3.<br>> > How do I f.i. listen to a 'pressed' signal on a QPushButton?<br>> > There is no 'pressed' method or procedure variable in the QAbstractButton interface which I could override.<br>> > Daniel, could you have a look at it? At worst the Qt port could be infunctional (Sorry, I haven`t tried that yet.).<br>> > Also I believe a full integration of Randys Trestle port could give us an additional backup if something did not work with the Qt port.<br>> ><br>> > and: Concerning the widechar support, 16bit characters will just be fine for Qt as it does internally use UTF-16 and thus UTF-16 character arrays can be directly converted into a QString. So if we would choose to introduce a 32bit character type I would give it another name like f.i. UCHAR in order not to break code that does rely on the current 16bit character width.<br>> ><br>> > Elmar<br>> ><br>> <br>> Just to be sure you understand, Modula-3 arrays of current-sized WIDECHAR<br>> are not UTF-16 character arrays. The former can only represent characters<br>> whose code points are <= 16_FFFF. UTF-16 encodes up to 16_10FFFF, by using<br>> two 16-bit code units for one character in the upper part of the range.<br>> This also means that the codes in the two code units are surrogates<br>> (16_D800..16_DFFF) and cannot be used as unencoded characters.<br>> <br>> For output, you could deal with this by just avoiding putting any surrogate<br>> values into a WIDECHAR (and, of course, no values beyond 16_FFFF, since they<br>> won't fit). But for input, any correctly implemented library that gives you<br>> UTF-16 strings could contain these, and probably you can't prevent that, because<br>> they can come all the way from a human user.<br>> <br>> So you would have to treat the WIDECHARs as code units, not code points, and<br>> write your own decoder. But then you would need a type to hold the decoded<br>> values, and WIDECHAR is not big enough, so it would have to be INTEGER or a<br>> subrange, and now you can't use the literals without conversions. Moreover,<br>> you can't use TEXT, with its easy-to-use functional style implementation of<br>> various string operations. I suppose you could write it so it just rejects<br>> or replaces high-valued code points at the decode stage and tell your users<br>> they can't use these characters.<br>> <br>> Or, you could just assume neither your application nor your users will ever<br>> need to use codes where 16-bit WIDECHAR and UTF-16 differ, and let it be buggy,<br>> if the assumption is ever violated.<br>> <br>> Also, does your preferred GUI allow you to specify that the UTF-16 strings<br>> you give it and get from it always have little endian code units, regardless<br>> of the native endianness of the machine? This is the way Modula-3 WIDECHARs<br>> work. If not, your application would only work on little-endian machines.<br>> <br></div> </div></body>
</html>