Friday, April 7, 2017

Digest for comp.lang.c++@googlegroups.com - 18 updates in 5 topics

"Chris M. Thomasson" <invalid@invalid.invalid>: Apr 07 01:00PM -0700

On 4/6/2017 3:13 PM, fir wrote:
> 1) you got much many cores there (even up to 10k parallel float channels there on the best cards)
> 2) heavy computational task concentrates in hot loops (thousands of parralel 'fibers' of the same computations not few of very different) and gpu model is more suitable for this
 
> if our idiot ramine will begin to write and optimise opencl kernels we could start talking
 
GPU is really suited for so-called embarrassingly parallel computations.
That's fine, and they really work well.
 
Fwiw, check this out, (needs WebGL):
 
http://funwithfractals.atspace.cc/ct_gfield_test/3d_user/ct_wormhole_exp.html
 
http://funwithfractals.atspace.cc/ct_gfield_test/ct_3dgfield_anime_test/
 
http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html
(clicking on a part of the fractal will zoom in)
 
Love the GPU! Just love it.
 
:^D
"Chris M. Thomasson" <invalid@invalid.invalid>: Apr 07 01:01PM -0700

On 4/6/2017 12:47 PM, Bonita Montero wrote:
>> I have tested them thoroughly and they are more stable and fast now.
 
> Don't trust in someone who claims to know how to write synchronization
> -facilities who doesn't even understand simple condidtion-variables.
 
Totally Agreed 100% Bonita!!!
David Brown <david.brown@hesbynett.no>: Apr 07 09:17AM +0200

On 07/04/17 01:25, Alf P. Steinbach wrote:
> UnicodeEncodeError: 'charmap' codec can't encode character '\xd8' in
> position 16: character maps to <undefined>
 
> [H:\forums\clc++\unicode in windows console]
 
I took a quick test on my Windows 7 system. It struggled with some of
the characters - it seems the modification character \u0333 is beyond
Window's abilities. And π is missing. With those removed, it worked.
 
Perhaps Windows console could print the Unicode characters, as long as
those characters happened to be in the normal Windows code page
(Latin-1, or something similar).
Alvin <Alvin@invalid.invalid>: Apr 07 02:06PM +0200

On 2017-04-07 09:17, David Brown wrote:
 
> Perhaps Windows console could print the Unicode characters, as long as
> those characters happened to be in the normal Windows code page
> (Latin-1, or something similar).
 
Windows works fine, if you set the codepage to UTF-8 (at least with a
terminal with good UTF support like ConEmu):
chcp 65001
 
It's not like it would work on Linux, if you have a non-UTF configuration:
 
> LC_ALL=en_US python3 unicode.py
 
Traceback (most recent call last):
File "unicode.py", line 5, in <module>
UnicodeEncodeError: 'latin-1' codec can't encode character '\u03c0' in
position 19: ordinal not in range(256)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 07 02:19PM +0200

On 07-Apr-17 9:17 AM, David Brown wrote:
>>> Hello, world - ÅØÆ πr² ïç a̳b
 
>>> Works fine with Python 2 or 3. It certainly works on my Linux machine -
>>> I expect it to work on Windows too.
 
[snip]
 
> I took a quick test on my Windows 7 system. It struggled with some of
> the characters - it seems the modification character \u0333 is beyond
> Window's abilities.
 
Yes, it is.
 
 
> And π is missing.
 
Whether you have π (pi) available with Python output depends on the
active codepage (the narrow character encoding) in the console, and the
reason that it depends on that, is Python's conversion from Unicode to
the active codepage, instead of using console i/o. I.e., to be less
imprecise, that the CPython implementation still does not support
Windows consoles but uses the standard narrow streams for console i/o.
 
Checking by simple
 
chcp CODEPAGENUMBER
echo π | more
 
… π appears to be there in codepages 437 (IBM PC, default in English
language installations of Windows) and 865 (Nordic), but appears to be
missing in codepages 865 (all-European) and 1252 (Windows ANSI Western,
an extension of ISO Latin-1), which some programmers use in the console.
 
But again, it would be impractical to keep changing the codepage to suit
the effective character set of the Python script. Instead CPython should
be fixed. I think that to get it fixed someone should argue that CPython
could be made even better (no mention of this being a fault).
 
 
 
> Perhaps Windows console could print the Unicode characters, as long as
> those characters happened to be in the normal Windows code page
> (Latin-1, or something similar).
 
Windows consoles handle the Basic Multilingual Plane just fine; Windows
console Windows are Unicode beasts through and through.
 
For example, you can use any BMP character in a typed in command, and
that command line is passed perfectly to the process.
 
Programs, such as the CPython implementation, and designs, such as the
design of the C++ i/o, fail to handle Unicode correctly in Windows.
Mainly because they are based on the antiquated and counter-productive
since 1981 old Unix unification of files, pipes and interactive i/o as
streams of single bytes. Even with UTF-8 and no support for interactive
features it's ungood, because UTF-8 error states are usually persistent.
 
 
Cheers & hth., :)
 
- Alf
alexo <alessandro.volturno@libero.it>: Apr 07 03:03PM +0200

I don't understand how 0xC2, 0xAC gives the cent symbol.
It is not a single character code, so how can this sequence interpreted
as a single character?
 
Same doubts in
 
0xE2, 0x82, 0xAC
or
0xF0, 0x90, 0x8D, 0x88.
 
> '\n',
> 0x00
> }
 
This arrays contains 19 or 11 characters (including in the counting 0x00
as '\0') ?
 
More over, reading the posts in this thread, I still have not understood
how to use wcout and unicode codes without having to write console
settings like
 
UINT oldcp = GetConsoleOutputCP();
 
if (!SetConsoleOutputCP(CP_UTF8))
{
fprintf(stderr, "chcp failed\n");
return EXIT_FAILURE;
}
 
I know I seem stupid, but I tought there were a way to write something like
 
 
std::wcout << "H\u0333" << "ello" << endl;
 
thank you
David Brown <david.brown@hesbynett.no>: Apr 07 03:37PM +0200

On 07/04/17 14:06, Alvin wrote:
> File "unicode.py", line 5, in <module>
> UnicodeEncodeError: 'latin-1' codec can't encode character '\u03c0' in
> position 19: ordinal not in range(256)
 
That is certainly true. But the difference is that the standard shells
and terminals on Linux have all been fine with utf-8 for a good many
years, and most systems will have a utf-8 locale even if they are only
used for plain ASCII characters normally. On Windows, however, you need
to go out of your way to get extra terminal software and have extra
settings (unless things have changed in later Windows).
 
Still, I will remember the possibility of something like ConEmu if I
find I need console utf-8 on Windows.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 07 03:37PM +0200

On 07-Apr-17 3:03 PM, alexo wrote:
> }
 
> I know I seem stupid, but I tought there were a way to write something like
 
> std::wcout << "H\u0333" << "ello" << endl;
 
Well, you could read my reply to your original posting.
 
That's a hint.
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Apr 07 03:44PM +0200

On 07/04/17 14:19, Alf P. Steinbach wrote:
> the active codepage, instead of using console i/o. I.e., to be less
> imprecise, that the CPython implementation still does not support
> Windows consoles but uses the standard narrow streams for console i/o.
 
That makes sense.
 
> language installations of Windows) and 865 (Nordic), but appears to be
> missing in codepages 865 (all-European) and 1252 (Windows ANSI Western,
> an extension of ISO Latin-1), which some programmers use in the console.
 
My code page at the moment is 850 (latin-1) - I have Windows set up for
UK English, but with a Norwegian keyboard. I can show π in a terminal,
with a suitable font like Lucida Console, but the python script still
does not print it.
 
> the effective character set of the Python script. Instead CPython should
> be fixed. I think that to get it fixed someone should argue that CPython
> could be made even better (no mention of this being a fault).
 
Yes - it would be nice if this simply worked cross-platform out of the
box on Windows. I suppose font support would be required, but it should
not be asking /too/ much of Python to make Unicode output work here on
Windows in the same way as on Linux.
 
> since 1981 old Unix unification of files, pipes and interactive i/o as
> streams of single bytes. Even with UTF-8 and no support for interactive
> features it's ungood, because UTF-8 error states are usually persistent.
 
Linux terminals can certainly be screwed up if you try and cat a binary
file. I don't know if it is only UTF-8 errors, or other problems. No
system is perfect, it seems.
 
 
> Cheers & hth., :)
 
Perhaps that is enough of this here - the Python stuff is off-topic for
c.l.c++ and I doubt if it is helping the OP. But thank you for your
explanations - I have learned a few new things here.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 07 03:46PM +0200

On 07-Apr-17 3:03 PM, alexo wrote:
> I don't understand how 0xC2, 0xAC gives the cent symbol.
> It is not a single character code, so how can this sequence interpreted
> as a single character?
 
You need to provide the full code and example for that.
 
Cheers!,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Apr 07 01:49PM


>Linux terminals can certainly be screwed up if you try and cat a binary
>file. I don't know if it is only UTF-8 errors, or other problems. No
>system is perfect, it seems.
 
Random terminal control escape sequences within the binary will screw up
xterm and gnome-terminal.
 
$ stty sane
$ tput reset
 
will restore normal operations. It may be necessary,
in some cases (^c of poorly written curses app, e.g.)
to use ^j to get a newline when typing stty sane.
 
 
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
Alvin <Alvin@invalid.invalid>: Apr 07 04:40PM +0200

On 2017-04-07 15:37, David Brown wrote:
> settings (unless things have changed in later Windows).
 
> Still, I will remember the possibility of something like ConEmu if I
> find I need console utf-8 on Windows.
 
I just tried Python 3.6.1. It works without chcp. There is PEP 528:
https://www.python.org/dev/peps/pep-0528/
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 07 07:52PM +0100


> I don't understand how 0xC2, 0xAC gives the cent symbol.
 
I don't think it ever will! 0xC2 0xAC is the hex encoding of the UTF-8
encoding of the not sign. A cent symbol is UTF-8 encoded as 0xC2 0xA2.
 
You need to anchor the distinction between the character set (loosely
the numbering of some collection of symbols) and the way in which those
numbers are encoded as bytes for transmission and/or printing. Unicode
is, to a first approximation, a numbering scheme for many hundreds of
characters. The numbers specified by Unicode can then be transmitted in
a variety of ways with names like UCS4, UTF-16 and UTF-8.
 
An excellent resource for learning about UTF-8 is this page:
 
http://www.cl.cam.ac.uk/~mgk25/unicode.html
 
<snip>
--
Ben.
ram@zedat.fu-berlin.de (Stefan Ram): Apr 07 12:34AM

It is conceivably, that when a vector is allocated or the
»push_back« member function is called, (dynamic) memory is
missing to accomplish the intention of that call.
 
Where does the standard specify behavior for this?
 
In 17.5.5.12p4 (was: 17.6.5.12p4) there is a sentence saying:
 
»Any other functions defined in the C++ standard library
that do not have an exception-specification may throw
implementation-defined exceptions unless otherwise specified.«
 
This should allow to throw an exception in the case of
missing memory. But is this the most specific sentence
about the behavior of »push_back« (and similar functions)
in the case of lack of (dynamic) memory in the standard?
ram@zedat.fu-berlin.de (Stefan Ram): Apr 07 02:29AM

Found this in cppreference.com: (begin of quotation)
 
S<int> s = {1,2,3,4,5}; // direct list-initialization
 
(end of quotation). It's a copy initialization
(copy-list-initialization)! You can call it
»direct list-initialization«, but it surely is not a
»direct-line-initialization« (note the hypen)!
ram@zedat.fu-berlin.de (Stefan Ram): Apr 07 01:07PM

>missing memory. But is this the most specific sentence
>about the behavior of »push_back« (and similar functions)
>in the case of lack of (dynamic) memory in the standard?
 
Found this:
 
20.10.9 The default allocator [default.allocator]
...
20.10.9.1 allocator members [allocator.members]
...
T* allocate(size_t n);
...
4 Throws: bad_alloc if the storage cannot be obtained.
Ron <ron.rwsoft@gmail.com>: Apr 06 06:53PM -0700

I did stumble across a solution for this problem and thought I'd share it. In the stream manipulator, I set the stream exceptions flags: ios->exceptions(std::ostream::badbit). This now lets exceptions thrown in the underflow method to be re-thrown and caught outside of the stream. When the socket read returns EAGAIN or EWOULDBLOCK I throw an ionotready exception that can be caught and sleep/attempts counter/failed actions can be take rather than locking up the program.
 
Hopefully this can help someone with a similar problem ;)
Ian Collins <ian-news@hotmail.com>: Apr 07 12:41PM +1200

On 04/ 7/17 12:34 PM, Stefan Ram wrote:
> missing memory. But is this the most specific sentence
> about the behavior of »push_back« (and similar functions)
> in the case of lack of (dynamic) memory in the standard?
 
By implication (push_back may call new), throwing std::bad_alloc.
 
--
Ian
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)