good to have typedef?

On Nov 6, 3:47 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Andy Champ wrote:
> > James Kanze wrote:

> >> In which case, uint32_t doesn't necessarily buy you that
> >> much. (It does restrict portability, however, since it is
> >> guaranteed not to be available on some machines.)

> > Luckily for _me_ I only need to worry about Windoze boxes -
> > albeit 64 bit is likely to come up soon. And I'm also lucky
> > that my byte order matches the spec. - not everyone does the
> > ISO 9660 trick of storing a number in both common orders,
> > it's not space efficient!

> > But what should I use if I want to represent a
> > guaranteed-to-be-32-bit quantity?

> uint32_t if the system has it. If not, define your own.

If he only has to worry about Windows, the system has it. On
systems which don't have it, however, defining your own might be
a bit difficult, and the type will probably be significantly
slower than one of the built-in types. (On at least one system,
the built-in unsigned types are significantly slower than the
the signed ones, because the hardware doesn't directly support
them.)

--
James Kanze

James Kanze

James Kanze wrote:

> On Nov 6, 3:47 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> Andy Champ wrote:
>>> James Kanze wrote:
>
>>>> In which case, uint32_t doesn't necessarily buy you that much. (It
>>>> does restrict portability, however, since it is guaranteed not to
>>>> be available on some machines.)
>
>>> Luckily for _me_ I only need to worry about Windoze boxes - albeit
>>> 64 bit is likely to come up soon. And I'm also lucky that my byte
>>> order matches the spec. - not everyone does the ISO 9660 trick of
>>> storing a number in both common orders, it's not space efficient!
>
>>> But what should I use if I want to represent a
>>> guaranteed-to-be-32-bit quantity?
>
>> uint32_t if the system has it. If not, define your own.
>
> If he only has to worry about Windows, the system has it. On systems
> which don't have it, however, defining your own might be a bit
> difficult, and the type will probably be significantly slower than
> one of the built-in types. (On at least one system, the built-in
> unsigned types are significantly slower than the the signed ones,
> because the hardware doesn't directly support them.)

I'm curious... what system doesn't "have" a uint32_t? I work also on
small 8bit micros (in C, but that's not really the issue here), and if I
really need it, I can use a uint32_t. It's not a native word size on
those systems, but the compiler couldn't care less about that. (Well,
the compiler writer of course does, and I do, too, where performance and
resources are an issue -- but the system "has it".)

Gerhard

Gerhard Fiedler

Nick Keighley wrote:

> Lovely bug:-
>
> Station_id read_station_id (FILE *in)
> {
> Station_id station_id;
> fscanf (in, "%d", &station_id);
> return station_id;
> }
>
> Station_id was a short.

You should get a compiler or linter that checks for such things -- or
use C++ streams in the first place

I found a few of these while porting a project from VC++ to gcc. gcc has
an option to check printf-type format strings.

Gerhard

Gerhard Fiedler

Gerhard Fiedler wrote:
> James Kanze wrote:
>
>> On Nov 6, 3:47 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> Andy Champ wrote:
>>>> James Kanze wrote:
>>
>>>>> In which case, uint32_t doesn't necessarily buy you that much.
>>>>> (It does restrict portability, however, since it is guaranteed
>>>>> not to be available on some machines.)
>>
>>>> Luckily for _me_ I only need to worry about Windoze boxes -
>>>> albeit 64 bit is likely to come up soon. And I'm also lucky
>>>> that my byte order matches the spec. - not everyone does the ISO
>>>> 9660 trick of storing a number in both common orders, it's not
>>>> space efficient!
>>
>>>> But what should I use if I want to represent a
>>>> guaranteed-to-be-32-bit quantity?
>>
>>> uint32_t if the system has it. If not, define your own.
>>
>> If he only has to worry about Windows, the system has it. On
>> systems which don't have it, however, defining your own might be a
>> bit difficult, and the type will probably be significantly slower
>> than one of the built-in types. (On at least one system, the
>> built-in unsigned types are significantly slower than the the
>> signed ones, because the hardware doesn't directly support them.)
>
> I'm curious... what system doesn't "have" a uint32_t? I work also on
> small 8bit micros (in C, but that's not really the issue here), and
> if I really need it, I can use a uint32_t. It's not a native word
> size on those systems, but the compiler couldn't care less about
> that. (Well, the compiler writer of course does, and I do, too,
> where performance and resources are an issue -- but the system "has
> it".)
>

Systems like these, that are based on 36-bit hardware

http://www.unisys.com/clearpath


Requiring them to have a uint32_t would be REALLY expensive. To top it
off, these machines also have 9-bit bytes, one's complement
arithmetic, and 72-bit non-IEEE floating point.

Unlike Java, C++ could actually be implemented.


Bo Persson

Bo Persson

On Nov 7, 7:44 pm, Gerhard Fiedler <geli...@gmail.com> wrote:
> James Kanze wrote:
> > On Nov 6, 3:47 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> Andy Champ wrote:
> >>> James Kanze wrote:

> >>>> In which case, uint32_t doesn't necessarily buy you that
> >>>> much. (It does restrict portability, however, since it
> >>>> is guaranteed not to be available on some machines.)

> >>> Luckily for _me_ I only need to worry about Windoze boxes
> >>> - albeit 64 bit is likely to come up soon. And I'm also
> >>> lucky that my byte order matches the spec. - not everyone
> >>> does the ISO 9660 trick of storing a number in both common
> >>> orders, it's not space efficient!

> >>> But what should I use if I want to represent a
> >>> guaranteed-to-be-32-bit quantity?

> >> uint32_t if the system has it. If not, define your own.

> > If he only has to worry about Windows, the system has it.
> > On systems which don't have it, however, defining your own
> > might be a bit difficult, and the type will probably be
> > significantly slower than one of the built-in types. (On at
> > least one system, the built-in unsigned types are
> > significantly slower than the the signed ones, because the
> > hardware doesn't directly support them.)

> I'm curious... what system doesn't "have" a uint32_t?

Neither of the Unisys mainframe architectures: one's 36 bit ones
complement, the other 48 bit signed magnitude (with 8 bits
reserved).

> I work also on small 8bit micros (in C, but that's not really
> the issue here), and if I really need it, I can use a
> uint32_t. It's not a native word size on those systems, but
> the compiler couldn't care less about that. (Well, the
> compiler writer of course does, and I do, too, where
> performance and resources are an issue -- but the system "has
> it".)

The compiler has to provide 32 bit arithmetic somehow, and if
the machine is 8 bits, using 32 bits for long, rather than more,
is the preferred solution. The problems are more with larger
machines, where the machine word size is 36 or 48 bits (or in
the past, 60 bits)---at one time, 36 bits was quite common.

--
James Kanze

James Kanze