Sunday, October 7, 2018

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 09:35PM +0100

I learned that very often the most intolerant and narrow-minded people are
the ones who congratulate themselves on their tolerance and open-mindedness.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 09:32PM +0100

I want to hear a lot more apologising from the faith-based communities for
the evil they have done before they even start clearing their throats and
telling me that I wouldn't know right from wrong without their permission.
I'm sorry, I won't be spoken to in that tone of voice.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 09:26PM +0100

So if your wife is pregnant and you know it's not you, the only
alternative is that it's the Holy Spirit?
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:31PM -0400

On 10/07/2018 04:26 PM, Rick C. Hodgin wrote:
> So if your wife is pregnant and you know it's not you, the only
> alternative is that it's the Holy Spirit?
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
You will see from the style of posts that the individual is quite
mad. He's jealous of the fact that I have something he doesn't,
and that I know where I'm going, and he still lives in fear.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 08:53PM +0100

If I could change one thing, it would be to dissociate the idea of faith
from virtue - now and for good - and to expose it for what it is: a
servile weakness, a refuge in cowardice, and a willingness to follow, with
credulity, people who are in the highest degree unscrupulous.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:29PM -0400

On 10/07/2018 03:53 PM, Rick C. Hodgin wrote:
> from virtue - now and for good - and to expose it for what it is: a
> servile weakness, a refuge in cowardice, and a willingness to follow,
> with credulity, people who are in the highest degree unscrupulous.
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
Jesus teaches us the way things are, not the way sin allows
us to only understand, which is to say not just the ways we
see here in this world with our eyes, and understand with
our minds which understand this world. There is more.
 
What God teaches us is that He created us for a purpose,
and that He has a plan for our lives. Those plans are be-
yond the confines of this world, and are eternal plans,
and are based on things our sin prevents us from seeing
or understanding, which are spiritual things.
 
But if you come to Jesus and ask forgiveness for your sin,
He opens up your understanding and reveals those portions
of your existence you could not yet know while your sin
remained.
 
--
Rick C. Hodgin
Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 04:30PM -0700

>> is also the case that the types in C++ must match the types in C,
>> but I haven't tried to verify that.)
 
> They must be type aliases in C, declared with typedef.
 
Sorry, I am guilty of using sloppy language. The names do
need to be declared in <stdint.h> as if they were declared
with a typedef. What I meant is they do not need to be
aliases for any standard integer type: they could instead be
aliases for extended integer types, and thus distinct types
from any standard integer type (and in particular the standard
character types). C and C++ both allow extended integer
types.
 
> C++ requires the types declared in C's stdint.h to have the same
> declaration in cstdint.
 
I believe that is not right. C++ n4659 21.4 covers <cstdint>,
and 21.4.1 p2 says
 
The header defines all types and macros the same as the C
standard library header <stdint.h>.
 
The types have to match, but not the declarations. The synopsis
directly under 21.4.1 make it clear that how the types are
declared in <cstdint> is different, or at least can be different,
than how they are declared in the C header <stdint.h>. Then in
section D.5, which discusses the C++ headers corresponding to C
headers, paragraph 3 says this:
 
Every other C header [including <stdint.h>], each of which
has a name of the form name.h, behaves as if each name placed
in the standard library namespace by the corresponding cname
header is placed within the global namespace scope, except
for the functions described in 29.9.5 [Mathematical special
functions], the declaration of std::byte (21.2.1), and the
functions and function templates described in 21.2.5 [byte
type operations]. It is unspecified whether these names are
first declared or defined within namespace scope (6.3.6) of
the namespace std and are then injected into the global
namespace scope by explicit using-declarations (10.3.3).
 
To me this looks like pretty convincing evidence that the types
have to be the same, but how they are declared does not.
Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 04:31PM -0700

>> Stronger type checking is another reason.
 
>> (*) Also other <stdint.h> types that could be character types.
 
> You can do that with `enum` types.
 
It also could be done using extended integer types, which IMO
would be a better choice.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 07 04:10AM +0200

On 07.10.2018 01:31, Tim Rentsch wrote:
 
>> You can do that with `enum` types.
 
> It also could be done using extended integer types, which IMO
> would be a better choice.
 
A compiler vendor can offer extended integer types. For a compiler
vendor it would not be reasonable to offer such types as `enum` types.
So that was not what I was talking about.
 
But you can not create extended raw integer types, without making your
own version of the compiler. You have to choose between either `enum` or
class type.
 
However, it's much easier to make your own compiler version now than it
used to be, especially with clang I believe. In the old days g++ was
implemented in pre-K&R C. And it was ugly. ;-)
 
 
Cheers & hth.,
 
- Alf
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 06 09:46PM -0700

On 9/18/2018 3:56 AM, Ralf Goertz wrote:
> do math with them, not to deal with characters.
 
> So what is the canonical way to input/output integral types of varying
> size (in my actual program I use templates)?
 
You want signed 8-bits use int8_t.
 
You want a signed char, use signed char. ;^)
 
signed char is at least 8-bits.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 11:16AM +0100

On Sat, 06 Oct 2018 16:30:42 -0700
> from any standard integer type (and in particular the standard
> character types). C and C++ both allow extended integer
> types.
 
You may be theoretically right, but it is entirely theoretical and is
never going to be done in practice for [u]int8_t. On any system
supporting [u]int8_t that you are going to come across in practice, char
will also be 8 bits in size. A C compiler is not going to provide
an extended integer type with the same size and other characteristics as
unsigned char and signed char just on the off chance that it might be
useful for C++'s type overloading on operator << when encountering
[u]int8_t, even if it could. I am not even sure that that would be
legal: "extended" implies something different to the standard integer
types, not something the same as a standard integer type.
 
> > declaration in cstdint.
 
> I believe that is not right. [snip]
> The types have to match, but not the declarations.
 
I think you are right about that. However, it doesn't change the
overarching point.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 11:36AM +0100

On Sun, 7 Oct 2018 11:16:44 +0100
> [u]int8_t, even if it could. I am not even sure that that would be
> legal: "extended" implies something different to the standard integer
> types, not something the same as a standard integer type.
 
The last point is also sort of implied by the wording for the fixed size
types in C99/11:
 
"These types are optional. However, if an implementation provides
integer types with widths of 8, 16, 32, or 64 bits, no padding bits,
and (for the signed types) that have a two's complement
representation, it shall define the corresponding typedef names."
 
You can only have the uint8_t typedef aliasing one integer type, and
likewise the int8_t typedef. As in practically all systems supporting
[u]int8_t, signed and unsigned char will be 8 bits without padding and
(for signed) with 2's complement representation, that implies you cannot
on such a system have identical but distinct types by some other name
for the [u]int8_t typedefs.
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 07 12:49PM -0400

On 10/07/2018 06:16 AM, Chris Vine wrote:
> On Sat, 06 Oct 2018 16:30:42 -0700
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
...
> never going to be done in practice for [u]int8_t. On any system
> supporting [u]int8_t that you are going to come across in practice, char
> will also be 8 bits in size.
 
That is absolutely mandatory. [u]int8 is required to have exactly 8
bits, they're not allowed to have padding bits. CHAR_BIT is required to
be >= 8. Since every non-bitfield type is required to occupy an integral
number of bytes, the only way that works is if CHAR_BIT == 8.
 
[u]int8_t can be a typedef for an extended integer type, but it must be
the same size as the character types.
 
...
> [u]int8_t, even if it could. I am not even sure that that would be
> legal: "extended" implies something different to the standard integer
> types, not something the same as a standard integer type.
 
You may consider that implied, but there's not a single clause in the
standard that would be violated by supporting such an extended type.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 07:27PM +0100

On Sun, 7 Oct 2018 12:49:34 -0400
> > types, not something the same as a standard integer type.
 
> You may consider that implied, but there's not a single clause in the
> standard that would be violated by supporting such an extended type.
 
I do consider it implied, so it follows that I disagree with you. See
also my other post on the issue.
 
In any event, no implementation that I know of does what you say, and I
do not think ever will.
David Brown <david.brown@hesbynett.no>: Oct 07 08:36PM +0200

On 07/10/18 20:27, Chris Vine wrote:
> also my other post on the issue.
 
> In any event, no implementation that I know of does what you say, and I
> do not think ever will.
 
In gcc implementations, these types are often defined with something like:
 
typedef __INT8_TYPE__ int8_t;
typedef __UINT8_TYPE__ uint8_t;
 
These types are internal symbols in the compiler - whether or not they
are "signed char" and "unsigned char" or extended integer types is not
particularly clear.
 
On the AVR port of gcc, they are defined as :
 
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
 
 
That is, they are defined as "int" and "unsigned int" with some
gcc-specific size modifications.
 
I have no idea /why/ they are defined this way. (I must remember to ask
one of the port maintainers about that!) But they are not simple
typedef's to signed and unsigned char.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 08:07PM +0100

On Sun, 7 Oct 2018 20:36:12 +0200
David Brown <david.brown@hesbynett.no> wrote:
[snip]
 
> I have no idea /why/ they are defined this way. (I must remember to ask
> one of the port maintainers about that!) But they are not simple
> typedef's to signed and unsigned char.
 
Is that a 8-bit processor, with chars and ints both of size 1? Or is
that implementation not strictly C conforming?
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 07 04:01PM -0400

On 10/07/2018 02:27 PM, Chris Vine wrote:
> On Sun, 7 Oct 2018 12:49:34 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/07/2018 06:16 AM, Chris Vine wrote:
...
>> standard that would be violated by supporting such an extended type.
 
> I do consider it implied, so it follows that I disagree with you. See
> also my other post on the issue.
 
So, if there is a clause that it violates, you can cite that clause and
explain how such an implementation would be considered in violation of
that clause.
David Brown <david.brown@hesbynett.no>: Oct 07 10:03PM +0200

On 07/10/18 21:07, Chris Vine wrote:
>> typedef's to signed and unsigned char.
 
> Is that a 8-bit processor, with chars and ints both of size 1? Or is
> that implementation not strictly C conforming?
 
It is an 8-bit processor, chars are 8-bit, but ints are 16-bit. It is
the "mode" attribute that determines the size of the type.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 09:23PM +0100

On Sun, 7 Oct 2018 16:01:24 -0400
 
> So, if there is a clause that it violates, you can cite that clause and
> explain how such an implementation would be considered in violation of
> that clause.
 
You seem super aggressive today.
 
I said it was implied, for reasons given in my earlier posts which you
are free to read at your leisure. That should make my position clear
enough I hope. The standard leaves many things implicit.
 
I am not asking you to agree with me. I am perfectly happy that you do
not.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 08:45PM +0100

If religious instruction were not allowed until the child had attained the
age of reason, we would be living in a quite different world.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 03:51PM -0400

On 10/07/2018 03:45 PM, Rick C. Hodgin wrote:
> If religious instruction were not allowed until the child had attained
> the age of reason, we would be living in a quite different world.
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
The enemy of God wants us to follow after worldly ways
so that he can sink his claws into our minds, corrupting
us away from God.
 
God teaches us to "Train up a child in the way he should
go, and when he is old he will not depart from it."
 
God has placed the appropriate raising of our children in our
hands, making it our responsibility. It is part of our duty
to serve God rightly in this world, by raising our children
rightly per His guidance and teaching and instruction, and in-
deed in all areas. Not as hypocrites, but as true servants of
God, as honorable men ... something Leigh Johnston does not
know anything about as you can see from the slander and hate
he posts against God.
 
--
Rick C. Hodgin
Paul <pepstein5@gmail.com>: Oct 07 12:28PM -0700

In the code below , TextNextNum has a constructor
of the form TestNextNum(const RandomGen&)
and DisplayNextNum has a constructor of the form
DisplayNextNum(const TestNextNum&)
 
I suspect that there's a problem below with using
the temporary variable RandomGen(Constants::testRandomNums, Constants::testProbabilities) as a parameter for the TestNextNum
constructor.
 
Is this a problem?
 
Thank you very much for your help,
 
Paul
 
 
DisplayExample::DisplayExample() :
DisplayNextNum(TestNextNum(RandomGen(Constants::testRandomNums, Constants::testProbabilities)))
 
{
// Some code
 
}
Paul <pepstein5@gmail.com>: Oct 07 09:18AM -0700

I understand from a previous thread (and thanks to everyone who answered there)
that the seed of a random number generator should be kept constant
throughout the running of the program.
The below is a bugged program which tries (but fails) to generate a
random uniform number between 0 and 1.
 
I am aware of good solutions to the problem by others, and have been
successful myself. However, the below code has a bug and I don't understand
why. It responds by choosing the same number each time it is called.
Why did I expect it to work? Well the static key word means that the
objects get set only the first time they go through the loop and retain
their state. And isn't that exactly what we want for the generator
and the distribution?
I would expect this code to be equivalent to distribution(generator);
distribution(generator);... and that would indeed generate different
numbers. So I'd be grateful for an explanation. Making the distribution
object non-static doesn't help either.
 
Many thanks for your help.
 
double RandomGen::nextDouble() const
{
static std::default_random_engine generator(0);
static std::uniform_real_distribution<double> distribution(0.0, 1.0);
return (distribution(generator));
}
Kai-Uwe Bux <bux_usenet@kubux.net>: Oct 07 04:58PM

On Sun, 07 Oct 2018 09:18:27 -0700, Paul wrote:
 
> successful myself. However, the below code has a bug and I don't
> understand why. It responds by choosing the same number each time it is
> called.
 
Which number ?
 
[Code in question:]
> 1.0);
> return (distribution(generator));
> }
 
How did you test this code? When I write a little test code like
 
#include <random>
#include <iostream>
 
double rand_double ( void ) {
static std::default_random_engine generator ( 0 );
static std::uniform_real_distribution<double> distribution ( 0.0,
1.0 );
return ( distribution( generator ) );
}
 
 
int main ( void ) {
for ( int i = 0; i < 10; ++ i ) {
std::cout << rand_double() << "\n";
}
}
 
I get:
 
0.131538
0.45865
0.218959
0.678865
0.934693
0.519416
0.0345721
0.5297
0.00769819
0.0668422
 
That looks pretty much random and between 0 and 1.
 
 
Best,
 
Kai-Uwe Bux
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 07 07:44PM +0100

> Why did I expect it to work? Well the static key word means that the
> objects get set only the first time they go through the loop and retain
> their state.
 
You need to post a complete program that exhibits the problem you are
describing. The fragment you show looks fine, so the problem may well
be else were.
 
--
Ben.
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)