5 ms·
> Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC. I hope it doesn't seem like I'm just moving the goalp
by TheNewAndy 10y ago
> Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC.
I hope it doesn't seem like I'm just moving the goalposts, but the obvious answer here is to use a type which is at least 8-bits wide if you only need 8-bits. Such a type exists, and is called "char" (with the appropriate signedness modifiers).
This whole discussion has been about writing portable code. Using a "char" here is going to work perfectly on your 8-bit uC. It is also going to work perfectly on your SHARC chip with 32-bit chars.
> If you are aware of a machine that provides that, yes! Otherwise, I'd suggest uint32_t.
I think we are talking about different things. I am talking about writing portable code. You are talking about writing code that only works on a particular machine (or the class of machines that have a 29-bit int).
I know there is a place for that code, and once you are writing code where you actually need to make use of knowledge about the machine, then I'm all for using types that make this clear. However, typically this code only lives at the edges of the system, and the actual "computation" can be written in portable, efficient, readable code without a great deal of trouble.
I'm completely aware that long can be 64-bits on some machines. If you care so much about the wasted memory, then uint_least32_t should make you happy - if you are happy with the C99 dependency (which can limit portability, though things are getting better), then I don't see how you can see this as being worse than the fixed width uint32_t.
Personally, I have found that while it sounds nice in theory, the domains I've been working in have meant that the memory doesn't make much difference (if it is just sitting on the stack or being passed between functions, then on 64-bit machines, there is typically no differences, as calling conventions tend to pad things out). It is only when you have an array of these in memory that it might start to matter, and here it tends not to matter a great deal - you are typically now optimizing an algorithm for an amd64 machine (read - it has plenty of memory) and the algorithm typically doesn't actually use a lot of it (since it needs to run on tiny micros too).
Anyway, I think we probably agree for code which isn't supposed to be portable. Potentially just that I tend to work more on the code that is supposed to be portable, and you work on the code at the edges?
- lake99 10y agoI did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I checked in code where I do math on char. It has to be on uint8 or int8 (or other widths). Not that I'd ever check in such code, after all, I agree with the company policy there. But "char" is just a part of the problem. We have the same issue with all kinds of bid-widths. When I read PC code with such names, I don't worry about their sizes, and just assume i386 conventions. When I read embedded C code with datatypes of undeclared widths, I get quite annoyed. Thankfully, I can't recall the last time I read such code. > then uint_least32_t should make you happy The thing is, I assume all uintX types to really mean at least X bits wide. I am aware that the compiler is free to use its discretion for allocating memory. I worry about finer details only when I need to.
- deleted 10y ago[deleted]
- TheNewAndy 10y agochar isn't fixed width. It is guaranteed to be at least 8-bits wide, but on a SHARC chip it is 32-bits wide. > The thing is, I assume all uintX types to really mean at least X bits wide. I am aware that the compiler is free to use its discretion for allocating memory. I worry about finer details only when I need to. That is explicitly not what they are. The standard is very clear that they must be exactly X bits wide, and if there is no type that is exactly X bits wide (and 2s compliment) then the types must not exist. But, if this is how you are treating these types, then aren't you basically just saying that in your mind you aren't using fixed width types? If everywhere you write uintX_t you are thinking "a type that is at least X bits wide", then you have to do all the reasoning as if the type is of an unknown width. It sounds like you have the worst of both worlds - the lack of portability of fixed width types combined with the slipperiness of minimum width types.
- lake99 10y agoThis miscommunication was my fault. We don't use uint8_t or other such things, we use uint8, uint16, etc. These are typedefed to compiler-specific types that guarantee a required minimum size. This is also the reason we are not allowed to do arithmetic on chars. The types we use may eventually get typedefed to a char, but at least when I see someone else's function that requires a char as opposed to uint8, I know he's dealing with actual characters. > then you have to do all the reasoning as if the type is of an unknown width Well, no. If we are writing portable math routines for such types, it gives us nice ranges for which the code should behave with correct answers or should throw red flags during unit testing.