Wednesday, January 13, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 01:31AM

>Specifically for MFC:
>And in Visual Studio MFC project I guess its better to use wstring
>rather than CString to manipulate the texts in files?
 
I think with windows internally, one uses UTF-16 (formerly UCS-2
and TCHAR and before that Windows-1252), but to exchange data with
other programs, UTF-8.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 05:15PM

>I think with windows internally, one uses UTF-16 (formerly UCS-2
>and TCHAR and before that Windows-1252), but to exchange data with
>other programs, UTF-8.
 
And an interesting web page in this regard is
 
utf8everywhere.org
 
.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 09:00PM

I just read a web page »Almost Always Auto« and wanted
to give it a try.
 
struct scanner
{ auto ch = unsigned char {};
... }
 
, but I immediately got
 
[Error] non-static data member declared 'auto'
 
. The compiler should be able to derive the type of »ch«.
Has this been forbidden due to some ideological reason?
ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 09:08PM

>struct scanner
>{ auto ch = unsigned char {};
> ... }
 
Next, I tried it on a block:
 
int main()
{ auto s = scanner {};
... }
 
and immediately got (for the line »{ auto s = scanner {};«):
 
internal compiler error: in gimplify_expr, at gimplify.c:8629
 
from GCC 5.1.1. That's not fair!
ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 09:09PM

>internal compiler error: in gimplify_expr, at gimplify.c:8629
 
However, rewriting the line with the »auto« to
 
scanner s{};
 
still gives this compiler error, so it has nothing
to do with »auto«.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 13 06:44PM

std::wstring is useless because "wide" characters are useless. You are
using it because Windows and/or Qt uses UTF-16? Well don't: UTF-8 is the
far superior choice and should be used in all of your code base except
at the OS/Framework API interface where you may have no choice but to
use "wide" characters sausages.
 
http://utf8everywhere.org/
 
/Flibble
Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 09:18PM +0200

On 13.01.2016 20:44, Mr Flibble wrote:
> at the OS/Framework API interface where you may have no choice but to
> use "wide" characters sausages.
 
> http://utf8everywhere.org/
 
I fully agree with this manifesto, and all my own code uses UTF-8
internally. But I think it would be still hard to convince Windows-only
programmers to use UTF-8 in their programs. Of course, they don't need
to use std::wstring either, CString would probably be fine for them.
 
Cheers
Paavo
JiiPee <no@notvalid.com>: Jan 13 07:19PM

On 13/01/2016 18:44, Mr Flibble wrote:
> but to use "wide" characters sausages.
 
> http://utf8everywhere.org/
 
> /Flibble
 
I guess one question is also that which one is easier to use. seems like
wstring makes things easier....
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 13 08:26PM

On 13/01/2016 19:19, JiiPee wrote:
 
>> /Flibble
 
> I guess one question is also that which one is easier to use. seems like
> wstring makes things easier....
 
Why do you think std::wstring makes things easier? It has absolutely no
advantages compared to UTF-8 apart from simplifying interfacing with a
pre-existing wide character API. In case you didn't know UTF-16 is also
a variable length encoding like UTF-8 so even that isn't a reason to use
it sausages.
 
/Flibble
legalize+jeeves@mail.xmission.com (Richard): Jan 13 08:47PM

[Please do not mail me a copy of your followup]
 
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
>internally. But I think it would be still hard to convince Windows-only
>programmers to use UTF-8 in their programs. Of course, they don't need
>to use std::wstring either, CString would probably be fine for them.
 
Nit: don't confuse "Windows-only programmers" with "MFC Programmers".
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
JiiPee <no@notvalid.com>: Jan 13 08:54PM

On 13/01/2016 20:47, Richard wrote:
>> programmers to use UTF-8 in their programs. Of course, they don't need
>> to use std::wstring either, CString would probably be fine for them.
> Nit: don't confuse "Windows-only programmers" with "MFC Programmers".
 
why would somebody do windows only programming :)?? going back to C
language??
JiiPee <no@notvalid.com>: Jan 13 01:24PM

On 13/01/2016 11:13, Paavo Helde wrote:
 
> If your projects are Windows-only, then always use UNICODE and use
> std::wstring. In this case the CString and std::wstring ought to be
> functionally the same, both should use UTF-16 encoding.
 
ok this was a good answer. I ll save this answer.
 
> The std::wstring has a bit safer and nicer interface than CString IMO,
> but it's up to your preferences which to use.
 
STL has also more functionality, isnt it? and it works with C++14.
ONe more thing: If I use wstring and manipulate file first with it and
then pass the result to CString, what is the best way to copy from STL
to CString? they both use UTF-16? -- so can I just copy the data byte by
byte or char by char?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 13 02:59PM +0100

On 1/13/2016 1:21 AM, JiiPee wrote:
 
> Specifically for MFC:
> And in Visual Studio MFC project I guess its better to use wstring
> rather than CString to manipulate the texts in files?
 
Not necessarily. As I recall CString provides practical printf-like
formatting functions and practical conversions. It's like, when in Rome,
do as the Romans, and when in Rama, do as the Ramans.
 
 
> CString to parse that? I kind of like wstring, but then I have to
> convert wstring to CString later on in the code....because MFC uses
> CStrings.
 
It may be that CString has some awful unpleasantness that means you
should avoid. I can't recall. But unless it's like that, I'd use the
framework's string type, same as if using e.g. Qt, use their strings.
 
Do note that Microsoft's documentation specifically states that the C
level `setlocale` does not accept UTF-8, that it will fail at any
attempt to set an UTF-8 locale. So UTF-8 is not a practical proposition
for narrow (`char`-based) strings in Windows. Even if a lot of Unix-land
programs have been ported to or co-developed for Windows with UTF-8
narrow string convention, so that there is absolutely no lack of people
who will recommend this and tell you that it works all fine & good, no
problemo. But I've never been particularly impressed by allegedly
Windows programs that e.g. don't manage to handle spaces in paths, or
paths with non-ASCII characters. I remember my early attempts to install
the Qt animal: the installation dialog was unable to handle the
backspace key (yes, it's true!), and I did NOT laugh. They just don't
test things for Windows, and then /believe/ that it works.
 
Cheers & hth.,
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 13 02:19PM

On Wed, 2016-01-13, JiiPee wrote:
>> environments.
 
> yes this one is what am doing currently. But the same question applies
> to all projects though.
 
Yes, but not the same /answer/, which was my point.
 
> only Windows. But obviously there is a possiblitity that programs need
> to run also on linux etc, so those things might need consideration. So
> far all my programs run only in Windows
 
It's possible that if you need to be portable between Windows
and the rest of the world, you need a third answer ... but I'm
no expert.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Jan 13 07:24AM -0800

On Wednesday, 13 January 2016 15:29:41 UTC+2, JiiPee wrote:
> then pass the result to CString, what is the best way to copy from STL
> to CString? they both use UTF-16? -- so can I just copy the data byte by
> byte or char by char?
 
Typically MSVC is configured so both contain exactly same UTF-16 so:
 
std::wstring ws;
 
// ... do stuff with ws

CString cs = ws.c_str();
 
// ... do stuff with cs
 
If It gives some warnings or errors about it then something is
apparently misconfigured.
 
Additionally, if you happen to use Windows COM (and that
likely happens sooner or later since lot of better things in
Windows are COM) then there is BSTR (again same UTF-16
text) and '_bstr_t' wrapper smart pointer for it.
JiiPee <no@notvalid.com>: Jan 13 04:15PM

On 13/01/2016 15:24, Öö Tiib wrote:
 
> std::wstring ws;
 
> // ... do stuff with ws
 
> CString cs = ws.c_str();
 
oh ok, it works so easily. although if I remember correctly I tried to
copy before like this but it did not work... but maybe I remember
wrongly. I ll try this.
JiiPee <no@notvalid.com>: Jan 13 04:24PM

On 13/01/2016 13:59, Alf P. Steinbach wrote:
 
> Not necessarily. As I recall CString provides practical printf-like
> formatting functions and practical conversions. It's like, when in
> Rome, do as the Romans, and when in Rama, do as the Ramans.
 
I see, but am I right that wstring has more functionality? STL is richer
than MFC (CString)?
Also if I use third party libraries (like xml parser/writer to store
setting to a file) then they propably use STL, right?
Also am a bit more familiar currently with wstring & STL than
MFC/CString... although its easy to use CString also. But I mean my
helper functions/tools for strings I create they are all done in STL.
Are these things important to consider as well?
 
I am not talking about handling strings in dialog boxes.... of course
there I use CString... but am talking about handling files and text in
them. Reading text from files and storing .
Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 06:58PM +0200

On 13.01.2016 18:15, JiiPee wrote:
 
> oh ok, it works so easily. although if I remember correctly I tried to
> copy before like this but it did not work... but maybe I remember
> wrongly. I ll try this.
 
Make sure you configure your MS projects as "Use Unicode character set"
(that's MS-speak for UTF-16). You can add this somewhere in your code to
be sure:
 
#if !defined(_UNICODE) || !defined(UNICODE)
#error Something wrong!
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)