Monday, January 4, 2016

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

JiiPee <no@notvalid.com>: Jan 04 12:53AM

On 03/01/2016 21:27, Paavo Helde wrote:
> Vir Campestris <vir.campestris@invalid.invalid> wrote in
> news:t5KdnfSA7-Kk4RTLnZ2dnUU78YednZ2d@brightview.co.uk:
 
> I still think using -1 is the simplest and most robust way. Cheers Paavo
 
I guess the question here is , what Vir also said, that is it
*guaranteed* by the standard that -1 *always* does this? So can you show
from the starndard the place which guarantees this? because if not, then
I think it might be risky to use it....(it might work in 99% of
machines, but fail in 1% which for me would mean I would not use it).
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 04 02:36AM +0100

On 1/4/2016 1:53 AM, JiiPee wrote:
 
> I guess the question here is , what Vir also said, that is it
> *guaranteed* by the standard that -1 *always* does this? So can you show
> from the starndard the place which guarantees this?
 
Unfortunately the standard treats initialization and arithmetic
separately, so we need to be precise about what "this" is.
 
I'll assume that it's
 
unsigned x = -1;
 
Then, first, C++11 §8.5/16 last dash, says that for this case
 
"Standard conversions (Clause 4) will be used, if necessary, to convert
the initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered"
 
And over in the referred clause 4 one finds in §4.7/2 that
 
"If the destination type is unsigned, the resulting value is the least
unsigned integer congruent to the source integer (modulo 2^n where n is
the number of bits used to represent the unsigned type)"
 
This is a bit UNCLEAR because it doesn't use the established term "value
representation", i.e. by not using that term it leaves open the
possibility of affecting some trap bits or such. But only the really
pedantic would fret about that. Nobody's posted a DR about it AFAIK.
 
 
Cheers & hth.,
 
- Alf
JiiPee <no@notvalid.com>: Jan 04 06:49PM

On 04/01/2016 01:36, Alf P. Steinbach wrote:
> "value representation", i.e. by not using that term it leaves open the
> possibility of affecting some trap bits or such. But only the really
> pedantic would fret about that. Nobody's posted a DR about it AFAIK.
 
ok, thanks for the effort
Vir Campestris <vir.campestris@invalid.invalid>: Jan 04 09:18PM

On 04/01/2016 00:53, JiiPee wrote:
> from the starndard the place which guarantees this? because if not, then
> I think it might be risky to use it....(it might work in 99% of
> machines, but fail in 1% which for me would mean I would not use it).
 
I've worked on machines where the difference between subsequent
addresses is 1, 6, 8, 18, 24 and 36 bits; and where the native word size
is 8, 16, 24, 32, 36 and 64.
 
As I said, I've never met one which is not twos complement (ie -1 is
some number of FFFs).
 
I have met some where +0.0 is different to -0.0 - but then, equality is
pretty meaningless in floating point.
 
If they do exist it's a hell of a lot less than 1%.
 
However - Alf told me not to do it. Paavo quoted me the spec (which I
spent 5 minutes reading again and again) and if those two tell me not to
I won't.
 
Andy
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 04 10:24PM

On Mon, 4 Jan 2016 21:18:59 +0000
 
> However - Alf told me not to do it. Paavo quoted me the spec (which I
> spent 5 minutes reading again and again) and if those two tell me not
> to I won't.
 
No they didn't. They told you that the initialization:
 
unsigned x = -1;
 
is guaranteed to initialize all the bits of the integer to 1, by §4.7/2
of the standard. It is guaranteed to work, subject to the slight
imperfection of the wording to which Alf referred but which does not
affect the clear intention. (However, behaviour in the reverse
direction, namely on overflow on conversion to signed, is not
guaranteed. It is implementation defined - §4.7/3.)
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 04 10:37PM

On Mon, 4 Jan 2016 22:24:16 +0000
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> does not affect the clear intention. (However, behaviour in the
> reverse direction, namely on overflow on conversion to signed, is not
> guaranteed. It is implementation defined - §4.7/3.)
 
It occurs to me that you may have been confused by the reference to bit
alteration in §4.7/2. The point here is that even where negative
numbers are represented by, say, one's complement
 
unsigned x = -1;
 
will still set all the bits of the integer to 1. However in one's
complement this is bit altering, because in the one's complement
representation of -1, the first bit is not set (all bits set in one's
complement is equivalent to -0, which is a value that two's complement
does not have).
 
Chris
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 04 10:54PM

On 04/01/2016 22:37, Chris Vine wrote:
> representation of -1, the first bit is not set (all bits set in one's
> complement is equivalent to -0, which is a value that two's complement
> does not have).
 
There is no such thing as negative 0 which makes (if you are correct)
one's complement erroneous. IEEE floating point is also wrong to include
support for negative 0 sausages.
 
/Flibble
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 04 11:08PM

On Mon, 4 Jan 2016 22:54:31 +0000
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
[snip]
> There is no such thing as negative 0 which makes (if you are correct)
> one's complement erroneous. IEEE floating point is also wrong to
> include support for negative 0 sausages.
 
On the mathematical number line, only 0 exists. But -0 exists in one's
complement. No bits set is +0, all bits set is -0. The two compare
equal so it is an artifact of the representation - in one's complement,
all bits set is equal to no bits set.
 
This is a necessary consequence of the fact that in one's complement
a negative number of a given value is obtained by inverting all the
bits of its positive equivalent. This in turn means that in one's
complement, the range of an 8 bit signed integer is 127 to -127, not
127 to -128 as in two's complement.
 
Chris
"Öö Tiib" <ootiib@hot.ee>: Jan 04 03:27PM -0800

On Tuesday, 5 January 2016 01:09:11 UTC+2, Chris Vine wrote:
> bits of its positive equivalent. This in turn means that in one's
> complement, the range of an 8 bit signed integer is 127 to -127, not
> 127 to -128 as in two's complement.
 
That is still unnecessary consequence. When we negate zero then it should
give zero again not "negative zero". The value with all bits set can be
used as "quiet saturating NaN" or even "Signaling NaN" ... such can be
useful. That -0 feels even less useful value than that -128.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 04 11:29PM

On 04/01/2016 23:08, Chris Vine wrote:
> bits of its positive equivalent. This in turn means that in one's
> complement, the range of an 8 bit signed integer is 127 to -127, not
> 127 to -128 as in two's complement.
 
The last time I had to think about 1's complement was in my first year
at university (1990) which just reinforces (in my mind) that 1's
complement is broken sausages.
 
/Flibble
scott@slp53.sl.home (Scott Lurndal): Jan 04 03:13PM

> WSAGetLastError()"
 
>> The documentation on FreeBSD and Linux says accept() returns a
>> non-negative number if successful.
 
In general, if an interface says it returns -1 on error, then the only
correct way to code the test is to compare directly to -1; it is
not correct to consider any value less than zero to be an error.
 
lseek() was a classic example of this when used with SVR4 /proc. The
off_t argument (and return value) needed to be treated as unsigned to
allow the entire process address space to be accessed.
 
mmap() is another example, where the special value "MAP_FAILED" is defined
for applications to check the return value against.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 04 10:10PM

On Mon, 2016-01-04, Scott Lurndal wrote:
 
> In general, if an interface says it returns -1 on error, then the only
> correct way to code the test is to compare directly to -1; it is
> not correct to consider any value less than zero to be an error.
 
Just for clarity (not to disagree) I'd like to point out again that
we're talking about /two different/ interfaces: Winsock and BSD
sockets.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Lynn McGuire <lmc@winsim.com>: Jan 04 03:32PM -0600

"C++17"
http://talesofcpp.fusionfenix.com/post-23/interlude
 
Lynn
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 04 12:39AM +0100

On 12/31/2015 6:31 AM, Alf P. Steinbach wrote:
 
>> https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1
 
> Checked in a fix for the cppx::is_empty function template
 
> https://github.com/alf-p-steinbach/cppx/commit/6bcf5be4b53e882dbf76b5414bfcf8820cddc240
 
Now, on Github:
https://github.com/alf-p-steinbach/cppx/commit/c7daa7c6decd4a48c1278217557eb4404f4c469a
 
Finally Unicode interactive line input so that this kind of beginner's
program now works as expected with non-ASCII characters in Windows:
 
<code>
#include <p/cppx/basics_and_main.hpp> // This header brings in a
default "main".
using namespace progrock::cppx;
 
void cpp_main()
{
// Basics: output of text parts, input of Unicode line.
sys.out << "Hi, what's your name? ";
const String username = line_from( sys.in );
sys.out << "Pleased to meet you, " << username << "!" << endl;
 
// Just to input at least 2 lines, so as to test the g++ workaround:
sys.out << endl;
sys.out << "What's your favorite activity, then, " << username << "? ";
const String activity = line_from( sys.in );
sys.out
<< "What a coincidence!" << endl
<< "Earlier I favored making Norwegian blåbærsyltetøy," << endl
<< "but now my favorite activity is also " << activity << "!"
<< endl;
 
sys.out << endl;
sys.out << "Well, have a nice day, " << username << "! Bye!" << endl;
}
</code>
 
Here
 
• The "'" apostrophe is displayed correctly (it's not in Latin-1).
 
• In Windows any character in Unicode's Basic Multilingual Plane should
work as input. Testing with "日本国 кошка" (a "Japanese cat", with
"Japanese" expressed in Chinese and "cat" in Russian, or I believe it's
so :) ) worked nicely, except the console window, with my choice of
font, was unable to display the Chinese glyphs.
 
• The narrow string literals are translated at run time using the code
page that the compiler encoded them with. In Windows this relies on a
simple text file that specifies that code page, e.g. "1252".
Unfortunately, as far as I know it can't be more automatically
determined, but I supply a little batch file that can generate the text
file; it just looks up the ACP codepage in the Windows registry.
 
Of course one doesn't need to use the library's "main", but it avoids
coding up a minimal exception-handling "main", and I believe that the
ability to just use a "cpp_main" and throw exceptions for failures, will
be useful to a beginner.
 
Probably next is making this work with g++, and then testing in
Unix-land. And then, not doing the constant-time-operations string
optimizations, which is much work for not much manifestly apparent gain,
but rather file operations, I think. Opening and creating files with
Unicode paths – in an amazing coincidence someone just now directed me
to my old code for that in an SO answer, by upvoting.
 
Constructive thoughts?
 
 
Cheers, & new year survival to all! :),
 
- Alf
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)