- Bug in my randomizer code - 2 Updates
- Faith - 1 Update
- Age of Reason - 1 Update
- int8_t and char - 21 Updates
| 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. |
| "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 |
| "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 |
| Tim Rentsch <txr@alumni.caltech.edu>: Oct 12 09:36PM -0700 > Then I get in return that I was changing the subject, as if I was not > comfortable with the current subject. That's a not nice behavior. I > want you to improve in that regard. My perception is you were changing the subject. If you had a different idea of what the subject was, then you may very well have thought you were keeping on the same subject. Sorry if there was a misunderstanding. |
| Tim Rentsch <txr@alumni.caltech.edu>: Oct 12 10:05PM -0700 >> separate precisely because they want C++ to take advantage >> of that. > I can't see how you can say it is a "strawman argument", [...] Sorry, I could have been more clear about that. What I meant by strawman argument is the statement "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," to which I pointed out that there are other reasons why a C implementation might make such a choice. >> type and an extended integer type. > I think this one has been beaten to death. I note that you don't > agree with me. We don't agree but I am saying something stronger. I haven't seen any evidence that supports your position. You have made /arguments/ but I don't remember seeing any /evidence/ that supports those arguments. Basically what you're offering (as I understand it, in case that needs saying) is an interpretation of various passages in the standard (or maybe standards plural), and some conclusions based on that interpretation. I accept that this interpretation is what you think. But I don't see anything specific that would motivate someone else to take the same view. Am I wrong about that? Are you offering something more than just your opinion? If so what is it? |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 06 08:47PM +0100 On Sat, 06 Oct 2018 11:36:18 -0700 > both the C standard and C++ standard allow this. (I believe it > 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. C++ requires the types declared in C's stdint.h to have the same declaration in cstdint. |
| 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. |
| Ralf Goertz <me@myprovider.invalid>: Oct 05 08:56AM +0200 Am Thu, 4 Oct 2018 17:15:29 +0100 > I don't seem to feel the angst others do with how the standard streams > print the value of the fixed or minimum sized integer types provided > by stdint.h. [OT] As a German it is always a bit strange to see or hear the word angst in a conversation in english. According to dict.leo.org it literally translates to its counterpart Angst with the modifiers "Lebensangst" (which describes the mood of hopelessness and fear of the future and which is rearely used AFAICT) or panisch (panic). Both those meanings I have a hard time recognising as appropriate here. This is probably another case of differences of dictionary definition and usage. One other expample being "idiosyncratic" for which the primary dictionary meaning apart from the medical term seems to be something like "unbearably disgusting" which rarely fits in the contexts I read or hear this word. > somewhat extreme to break congruity with C and make all the fixed and > minimum width types in stdint.h their own distinct types just to > please operator << and >>. But you wouldn't need to break congruity, would you? I don't know that much C but it doesn't have the *stream* operators << and >>. So it would have been possible to make [u]int8_t a separate type which behaves like [un]signed char in all aspects shared between C and C++ and still define those operators to behave the way you would expect from integer types. |
| 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 05 12:39PM +0100 On Fri, 5 Oct 2018 08:56:54 +0200 > Am Thu, 4 Oct 2018 17:15:29 +0100 > schrieb Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: [snip] > have been possible to make [u]int8_t a separate type which behaves like > [un]signed char in all aspects shared between C and C++ and still define > those operators to behave the way you would expect from integer types. I do not think that it is possible to "make [u]int8_t a separate type which behaves like [un]signed char in all aspects shared between C and C++ and still define [operators << and >>] to behave the way you would expect from integer types". To provide overloading on operator << and >> then uint8_t would require to be a distinct type, rather as wchar_t is (and presumably you would apply this to each fixed or minimum width type). But if you did that then uint8_t and the other fixed and minimum width integers _would_ behave differently between C and C++. In particular, code which does not break the strict aliasing rule in C might break it in C++. |
| 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 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 05:05PM -0400 On 10/07/2018 04:23 PM, Chris Vine wrote: > 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. The only reasons you gave aren't sufficient to make an implementation non-conforming. Someone could say "I think the term 'null pointer constant' implies that it must have a pointer type" - but the fact that he feels that way wouldn't make an implementation that recognizes 0 ans an NPC non=conforming. |
| 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. |
| Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 11:36AM -0700 >> name that matches the usage. > Yes, maybe I misunderstood Tim and he just talked about using the > "char" *name*. Agreed this should not be used for non-strings. My comment was about the 'char' type, not the name. I suppose there could be cases where using the 'char' type but with a different name could be a good choice for some small integer type, although I haven't yet thought of one. > However, the problem is that std::int8_t and std::uint8_t > are really just typedefs, not real types, They could be typedefs, or they could be distinct types. AFAICT both the C standard and C++ standard allow this. (I believe it is also the case that the types in C++ must match the types in C, but I haven't tried to verify that.) > which makes them just > cosmetics and makes it impossible to fix the std stream behavior, for > example. Personally I would prefer the [u]int8_t types in particular(*) to be distinct from the standard character types, to accommodate better behavior with respect to streams among other reasons. Stronger type checking is another reason. (*) Also other <stdint.h> types that could be character types. |
| 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. |
| "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. |
| 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. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 08 12:22AM +0100 On Sun, 7 Oct 2018 17:05:32 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: [snip] > constant' implies that it must have a pointer type" - but the fact that > he feels that way wouldn't make an implementation that recognizes 0 ans > an NPC non=conforming. That is a complete non-sequitur. The standard explicitly states that 0 is a null pointer constant, so implication plays no role: "A null pointer constant is an integer literal with value zero or a prvalue of type std::nullptr_t". |
| Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 05:45AM -0700 > including 8-bit, in order to reduce the memory footprint and enhance > the performance with large arrays. It's sad to hear I'm not sensible > ;-) Did you use signed/unsigned char, or just plain char? My comment was only about char, not signed char or unsigned char. |
| 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. |
| "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 |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 06 09:13PM +0200 On 06.10.2018 20:36, Tim Rentsch wrote: > better behavior with respect to streams among other reasons. > Stronger type checking is another reason. > (*) Also other <stdint.h> types that could be character types. You can do that with `enum` types. I discovered that there's a difference between doing it with `enum` type and doing it with a `struct` type when I tried to define an UTF-8 encoding unit type to use instead of `char`. Namely, that the `enum` is compatible with the common small buffer optimization of `std::string`, which typically uses a `union`, while the `struct` type isn't. Or wasn't: the rules may have changed a little, C++ has generally gotten a little more permissive. That permissiveness includes that there's now a Defect Report for the wording in the standard that it's Undefined Behavior to cast a value to an `enum` when its outside the range of values defined for the `enum`, even when it's in range for the underlying type. That UB, known to everybody else, was discovered by the mighty as a consequence of scrutinizing the definition of `std::byte`. So `std::byte` was good for /something/, hallelujah :) Cheers!, - Alf |
| 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? |
| 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. |
No comments:
Post a Comment