Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167662
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Beginner....Decimal/Octal converter help |
| Date | 2022-09-13 12:31 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <tfpm5j$2idls$1@dont-email.me> (permalink) |
| References | (11 earlier) <87r10hzn19.fsf@bsb.me.uk> <tfnh5k$29dcu$1@dont-email.me> <87mtb4wq4f.fsf@bsb.me.uk> <tfnnob$1d8r$1@gioia.aioe.org> <875yhswfiv.fsf@bsb.me.uk> |
On 12/09/2022 21:37, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 12/09/2022 16:48, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> In the vast majority of cases, when I see intN_t I feel that
>>> int_leastN_t or int_fastN_t would be better, because none of extra
>>> guarantees of intN_t are needed. I usually just think "ah, this person
>>> does not know about the alternatives".
>>>
>>>> I think to some extent it comes down to a subjective opinion of what
>>>> we are willing to be wrong about and what we prefer to be correct
>>>> about in how we code. There are always compromises.
>>> What are some good examples if the use of the intN_t types?
>>
>> Of fixed width integer types in general?
>
> No. Cases where intN_t is better than ether int_lastN_t or int_fastN_t,
> except (and I've made this exception clear from the start) matching
> externally imposed size requirements.
My argument is not so much that "intN_t" types are really /better/ than
"int_leastN_t" or "int_fastN_t", but that the "least" and "fast"
versions are not noticeably better. In most situations, /none/ of these
types express /exactly/ what you want, with no more and no less.
Generally, they all specify features that don't matter at the time. So
the simpler and clearer choice then wins overall. (We may have
different ideas about what "better" means.)
Code does not exist in a vacuum (except for snippets posted in some kind
of discussion forum, which is why examples here would likely be
pointless). I have already made several comments about why I think a
smaller number of types is better than a proliferation of types that
appear similar. Another that has been mentioned is interfacing to
existing code and functions - if your code is using library calls that
expect a "u32" parameter, then perhaps "u32" is the best type for your
local variable. If you are maintaining code that uses "byte" and
"dword" and adding a new function, then "dword" could well be the best
type. If you are writing code that will be seen by others, and you
don't have the time to explain the difference between unfamiliar
"int_fast32_t" and familiar "int32_t", then "int32_t" is a better choice.
C has quite a number of integer types (including those from the standard
library), with lots of different combinations of features. It does not
have all the combinations that I want - and I am surely not alone in
that (though exactly what people want will differ). Equally, most code
only requires a few integer types at a time. For a lot of it, "int" is
sufficient.
Perhaps if a large proportion of C programmers had been re-educated when
C99 came out, and encouraged in new directions, then the "fast" and
"least" types could have become popular - and then they would have been
the "better" choice much more often. But that didn't happen. Remember,
only a tiny proportion of C programmers have read the standards -
features that are rarely used in real code, will be unfamiliar to most C
programmers.
I am not in any way suggesting that it is a good idea to follow bad
habits of other programmers, nor even saying that we should limit the
language features we use in order to suit the lowest common denominator.
But I also don't think it is helpful to use a relatively unknown
feature that has, at most, subtle and symbolic benefits.
While thinking about newer C features, I have found another challenge
with using multiple different sometimes incompatible aliases for integer
types - _Generic. I don't know if you've used _Generic much, but it can
sometimes be useful. Here is a small example :
#include <stdint.h>
#include <inttypes.h>
#include <stdio.h>
#define print_var(_x) \
do { \
printf("Var " # _x " = "); \
printf( \
_Generic(_x, \
uint8_t : "0x%02" PRIx8, \
uint16_t : "0x%04" PRIx16, \
uint32_t : "0x%08" PRIx32, \
uint64_t : "0x%016" PRIx64), \
_x); \
printf("\n"); \
} while (0);
(Unfortunately the "result" of a _Generic doesn't count as a string
literal, and can't be directly concatenated with the other bits of the
string.)
You can use it like this :
void printtest(uint8_t x, uint16_t y, uint32_t z, uint64_t w) {
print_var(x);
print_var(y);
print_var(z);
print_var(w);
}
So far, so good. What about the "least" types? We can't add them to
the list as the _Generic would be ambiguous. Fortunately, in the real
world (excluding DSP's) the "least" types are always identical to the
fixed-size types, so the _Generic works unchanged.
void printtest2(uint_least8_t x, uint_least16_t y,
uint_least32_t z, uint_least64_t w) {
print_var(x);
print_var(y);
print_var(z);
print_var(w);
}
But when we get to the "fast" types, the fun starts :
void printtest3(uint_fast8_t x, uint_fast16_t y,
uint_fast32_t z, uint_fast64_t w) {
print_var(x);
print_var(y);
print_var(z);
print_var(w);
}
For one thing, the person expecting to see a 16-bit "y" sees 16 hex
digits, not 4. But try compiling this for 32-bit ARM (here's a godbolt
link: <https://godbolt.org/z/TP3sMnTsG> ). It turns out that on that
platform, "uint32_t" is "unsigned long int", while "uint_fast32_t" is
"unsigned int". So now our nice neat _Generic needs to have an extra line :
uint_fast32_t : "0x%08" PRIxFAST32, \
and that also matches "uint_fast16_t".
But now try compiling this for 64-bit x86. Here, "uint_fast16_t",
"uint_fast32_t" and "uint_fast64_t" are all "unsigned long long int" -
colliding with "uint64_t".
If you stick to a simple set of fixed-size types, the _Generic
statements are clear, follow a nice pattern, and give the user the
expected results. Mixing the "fast" types spoils all that.
Certainly _Generic is a bit niche, and not commonly used - I'd believe
you if you said that many more people know about "uint_fast16_t" than
_Generic. But it is an indication of how a simpler and more limited
selection of types can lead to simpler and neater code, and fewer
unexpected effects.
(I think it is also fair to argue that this example shows a flaw in
_Generic - it would arguably have been better to allow compatible types
to appear multiple times as long as the resulting expression is the same
in each case.)
>
>> * Specifying narrow storage types for efficient memory use of arrays
>> and structs
>
> So why not int_leastN_t?
The question is rather, /why/ int_leastN_t ? It doesn't give you a
smaller type, it just gives the reader bigger uncertainty. Some people
will be quite happy not knowing the underlying details, others prefer to
know them.
>
>> * Optimising layouts of structs
>
> I'd prefer an actual example to know what you mean. It may count, but
> most optimising of structs is really down to the compiler.
Compilers do not do much optimising of structs. It's been tried (by gcc
at least), but was then removed because the complications of dealing
with re-arranged structures across different translation units meant it
could rarely be used safely. I believe there are new developments
underway to do it in connection with link-time optimisation.
The ABI for any given implementation will determine structure padding
and alignment rules, and the compiler will handle these automatically.
However, sometimes you want tighter control - even when you are not
talking about matching external structures (file structures, network
structures, hardware peripherals, etc.). A common example is to match
cache line sizes for arrays, which can make a significant difference to
the efficiency of some kinds of code. For smaller processors, it may
even be useful to match powers of two for more efficient indexing of
arrays, though such devices without multiplication instructions are a
dying breed.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Beginner....Decimal/Octal converter help ManyBeers <markzuffi@yahoo.com> - 2022-09-08 11:34 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-08 11:56 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-08 20:19 +0100
Re: Beginner....Decimal/Octal converter help Barry Schwarz <schwarzb@delq.com> - 2022-09-08 12:34 -0700
Re: Beginner....Decimal/Octal converter help Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-08 20:38 -0600
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-09-09 03:22 -0700
Re: Beginner....Decimal/Octal converter help gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-09 13:30 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-09 09:16 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 19:06 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 11:58 +0200
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 11:37 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 13:05 +0200
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-10 14:42 +0000
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 16:10 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 18:14 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 12:54 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 16:22 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 19:03 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 19:30 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 19:47 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-11 14:07 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 16:12 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-11 17:58 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 21:14 +0100
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 20:01 -0700
Re: Beginner....Decimal/Octal converter help Richard Damon <Richard@Damon-Family.org> - 2022-09-11 23:32 -0400
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:52 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 03:24 -0700
Re: Beginner....Decimal/Octal converter help Richard Damon <Richard@Damon-Family.org> - 2022-09-14 08:10 -0400
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 06:09 -0800
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-12 16:53 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 16:48 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-12 17:46 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 20:37 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 00:03 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-13 12:31 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-13 12:48 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 14:18 +0100
Re: Beginner....Decimal/Octal converter help Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-13 17:13 +0300
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-13 16:50 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 18:47 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 03:16 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-13 20:15 +0200
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 20:29 +0000
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 22:22 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 14:37 -0700
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 23:16 +0100
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-13 22:16 +0000
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 16:15 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 16:15 -0700
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-14 10:58 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 15:36 +0100
Re: Beginner....Decimal/Octal converter help Richard Harnden <richard.nospam@gmail.com> - 2022-09-14 21:53 +0100
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 05:55 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:10 +0200
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 07:54 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 18:32 +0200
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-14 18:39 +0100
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:12 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-15 09:11 +0200
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 08:07 -0700
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 18:40 +0000
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 05:45 +0000
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 12:11 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 09:57 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 03:09 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:29 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 15:14 +0100
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:36 -0700
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-10-03 01:10 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-03 11:36 +0100
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-10-04 02:13 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-04 16:27 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 11:48 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:38 +0200
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-14 14:27 +0000
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 07:58 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 13:06 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-16 13:16 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:55 +0000
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-12 18:22 +0000
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 20:41 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 15:45 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 15:41 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-12 17:06 +0200
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:46 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:57 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 07:07 -0700
Neologism (Was: Beginner....Decimal/Octal converter help) gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-11 14:18 +0000
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:33 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:40 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 23:08 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:37 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:31 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:44 -0700
csiph-web