- uint32_t is not the same as long unsigned int ? - 5 Updates
- Union type punning in C++ - 13 Updates
- Don't be fooled by cpp.sh - 1 Update
- little contest - 6 Updates
| wolfgang bauer <schutz@gmx.de>: Jan 04 04:50AM +0100 Hi A Question about Datatypes: uint32_t x; printf("%lu\n", x); That results in this warning: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' So the compiler states: uint32_t is unsigned int. I thought, uint16_t is unsigned int. I thought, "int" is 16 Bit. And so "long int" should be 32 Bit. Am i wrong with that ? If it is important for the answer: I'm working here with Linux 64-Bit, CodeLite / gcc. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 03 11:18PM -0500 On 1/3/20 10:50 PM, wolfgang bauer wrote: > I thought, uint16_t is unsigned int. > I thought, "int" is 16 Bit. And so "long int" should be 32 Bit. > Am i wrong with that ? Yes. char, signed char, and unsigned char must have at least 8 bits. short, unsigned short, int, and unsigned int must have at least 16 bits. long and unsigned long must have at least 32 bits. long long and unsigned long long must have at least 64 bits. However, any of those types can have more than the minimum number of bits. The exact sized typedefs from <cstdint> are optional, but if supported, must have exactly the specified number of bits - so you should not make assumptions about which standard types they are typedefs for. The actual requirements are in terms of the required range of values that each standard integer type must be able to represent, and are incorporated by reference from the C standard. I've converted those ranges into bit counts to better match your question. > If it is important for the answer: I'm working here with Linux 64-Bit, CodeLite / gcc. One a 64-bit machine, long is often a 64-bit type, with int being a 32 bit type. |
| wolfgang bauer <schutz@gmx.de>: Jan 04 05:36AM +0100 04.01.20 , 05:18 , James Kuyper: >> If it is important for the answer: I'm working here with Linux 64-Bit, CodeLite / gcc. > One a 64-bit machine, long is often a 64-bit type, with int being a 32 > bit type. If I remove the "l" from "lu" in the print-function, no warning appear. This fits to your explanation. And so printf("sizeof int %d\n", sizeof(int)) has 4 as result. So on a 32-Bit machine it would be 2. Thank you for this helpful answer. |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 04 12:19AM -0600 On Sat, 4 Jan 2020 05:36:17 +0100, wolfgang bauer <schutz@gmx.de> wrote: >This fits to your explanation. >And so printf("sizeof int %d\n", sizeof(int)) has 4 as result. So on a 32-Bit machine it would be 2. >Thank you for this helpful answer. On most 32-bit implementations, sizeof(int) is 4. sizeof(int) being 2 was common on 16-bit implementations. |
| Barry Schwarz <schwarzb@delq.com>: Jan 03 10:29PM -0800 On Sat, 4 Jan 2020 05:36:17 +0100, wolfgang bauer <schutz@gmx.de> wrote: >If I remove the "l" from "lu" in the print-function, no warning appear. >This fits to your explanation. >And so printf("sizeof int %d\n", sizeof(int)) has 4 as result. So on a 32-Bit machine it would be 2. Firstly, sizeof evaluates to a size_t which need not be int. Printing it with %d is not portable, could lead to undefined behavior, and some compilers will diagnose this. Either use %zu which is designed for size_t or cast the value to a type that matches your format, in this case int. Secondly, on a 32-bit machine, sizeof(int) will almost always be 4. It may be 2 on a 16-bit machine. It really depends on what the compiler writer decided to do. If your code depends on an int having a particular size, test for it and abort if you don't get the value you want. Alternately, you could use the exact size typedef for what you need. If the typedef is not available, your code will not compile, identifying the problem immediately. If it does compile, you know you are using the size you want. -- Remove del for email |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 04 12:11AM On 03/01/2020 22:59, Melzzzzz wrote: >>> not particularly useful. >> Afaict, its going to be rather "tedious" to get it done in C++. Humm... > Or at all needed... It is needed to make client-site code as simple/clean/elegant as possible: clean: v.x = 42; f(v.x) not-clean: v.set_x(42); f(v.x()); /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:21AM > v.x = 42; f(v.x) > not-clean: > v.set_x(42); f(v.x()); It's just syntax. Preference. Object vs functional style. We all know that is advisable not to touch member variables directly. When that changed? -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:25AM +0100 > For small blocks movs instructions are better. > For big ones opposite. The compiler knows better than stupid Melzzz. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 04 12:26AM On 04/01/2020 00:21, Melzzzzz wrote: > Object vs functional style. > We all know that is advisable not to touch member variables directly. > When that changed? There isn't a class invariant so it is no different to using a "struct" (yes, I know there isn't much difference between "struct" and "class" in C++). /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:26AM +0100 > [...] > It seems like a static_assert to ensure that a double is the same size > as a unit64_t is in order? ... LOL, in that _experimental_code_ just to prove that memcpy() is translated into efficient moves? |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:28AM >> For small blocks movs instructions are better. >> For big ones opposite. > The compiler knows better than stupid Melzzz. Nope. These two don's agree but: ~/examples/assembler >>> ./rdtscp 200 [32] 200 128 byte blocks, loops:20000 rep movsb 0.00000054797211 rep movsq 0.00000054844105 movntdq 0.00000065490963 movntdq prefetch 0.00000063764716 movntdq prefetch ymm 0.00000063049784 ~/examples/assembler >>> ./rdtscp 4 [32] 4 128 byte blocks, loops:1000000 rep movsb 0.00000004582558 rep movsq 0.00000002845861 movntdq 0.00000008605540 movntdq prefetch 0.00000008531304 movntdq prefetch ymm 0.00000008636872 see, it's all empyrical... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:41AM +0100 > movntdq prefetch 0.00000008531304 > movntdq prefetch ymm 0.00000008636872 > see, it's all empyrical... That's not as easy to test as you might think. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:52AM >> movntdq prefetch ymm 0.00000008636872 >> see, it's all empyrical... > That's not as easy to test as you might think. It is not easy, that is why I wrote tests... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 03 04:55PM -0800 On 1/3/2020 4:26 PM, Bonita Montero wrote: >> as a unit64_t is in order? ... > LOL, in that _experimental_code_ just to prove > that memcpy() is translated into efficient moves? Color me pendant... ;^) |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 01:02AM >> LOL, in that _experimental_code_ just to prove >> that memcpy() is translated into efficient moves? > Color me pendant... ;^) Not once I saw examples when compiler (gcc) returned garbage in different scenarios. That code screams 'volatile' ;) -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 03 05:06PM -0800 On 1/3/2020 5:02 PM, Melzzzzz wrote: >> Color me pendant... ;^) > Not once I saw examples when compiler (gcc) returned garbage > in different scenarios. That code screams 'volatile' ;) Actually, portability be damned, I used 64 bit atomics to work with doubles that happened to be of the same size. It was a fast and dirty way to work on doubles atomically. Well, I only used it for atomic swap, compare-exchange, load and store. NO fetch-and-add. It would destroy things. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 03 06:47PM -0800 On 1/3/2020 4:11 PM, Mr Flibble wrote: >>> Afaict, its going to be rather "tedious" to get it done in C++. Humm... >> Or at all needed... > It is needed to make client-site code as simple/clean/elegant as possible: The cleaner the better, wrt trying to port GLSL code to its C++ "equal". It can be done, and a nice std swizzle would be great. Now, going from C++ to GLSL is easy, in a sense. The other way around, sometimes, get ready for fun! ;^o > v.x = 42; f(v.x) > not-clean: > v.set_x(42); f(v.x()); I see, indeed. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 03 07:07PM -0800 On 1/3/2020 6:47 PM, Chris M. Thomasson wrote: > It can be done, and a nice std swizzle would be great. Now, going from > C++ to GLSL is easy, in a sense. The other way around, sometimes, get > ready for fun! ;^o [...] I have to admit that this is sort of "selfish". Imvvho, I would not object to C++ supporting some sort of GLSL like swizzle. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 03 09:05PM -0500 On 1/3/20 1:29 PM, Keith Thompson wrote: ... > (My own conclusion is that the lack of supporting normative text is a > flaw in the C standard. It should make a clear normative statement > about the behavior of type punning using union members.) Agreed. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:04AM +0100 >> I've developed one with this JSON-parser: >> https://github.com/open-source-parsers/jsoncpp > I hate writting parsers in C++, especially in C. Writing parsers is always a industrious task, but in C++ it's rather convenient. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:17AM >> I hate writting parsers in C++, especially in C. > Writing parsers is always a industrious task, > but in C++ it's rather convenient. How so? -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:20AM +0100 >> Writing parsers is always a industrious task, >> but in C++ it's rather convenient. > How so? https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html ... and many other parser-libs. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:26AM >> How so? > https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html > ... and many other parser-libs. Having library is necessary, as it is tedious to write parser in C++... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 04 01:27AM +0100 >> https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html >> ... and many other parser-libs. > Having library is necessary, as it is tedious to write parser in C++... That's in every language "tedious". |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 04 12:29AM >>> ... and many other parser-libs. >> Having library is necessary, as it is tedious to write parser in C++... > That's in every language "tedious". Nope. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| 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