Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

usage of uin16_t

0 views
Skip to first unread message

Pavan

unread,
Mar 30, 2009, 6:06:53 AM3/30/09
to
Hi Can you clarify following questions regarding uint16_t

1> Does uint16_t is supported by Windows compilers also? If not on
checking what define, I should typedef. I mean to say for eg:
#ifdef WIN32
typedef unsigned short uint16_t;
#endif

2> When I use uint16_t am I always guaranteed that it cannot hold more
than 16 bits
Eg: uint16_t x = 0xffffffff; // Is it always guaranteed that the value
written is only 0xffff

Alf P. Steinbach

unread,
Mar 30, 2009, 6:30:03 AM3/30/09
to
* Pavan:

> Hi Can you clarify following questions regarding uint16_t
>
> 1> Does uint16_t is supported by Windows compilers also?

Presumably the "also" means that you're currently using some non-Windows
compiler where there is support for uint16_t.

Type "wikipedia uint16_t" in the Firefox address bar served up a list of Google
hits; the first was <url: http://en.wikipedia.org/wiki/Stdint.h>.

And that article says "The exact-width types and their corresponding ranges are
only included in that header if they exist for that specific compiler/processor.".

By the way, if a particular compiler doesn't offer [stdint.h] then check out the
Boost equivalent.

> 2> When I use uint16_t am I always guaranteed that it cannot hold more
> than 16 bits
> Eg: uint16_t x = 0xffffffff; // Is it always guaranteed that the value
> written is only 0xffff

See above. That is, as we said in the old days, RTFM. :) Of course, you'd have
to find the/a manual first, but it's not really that hard (see above).


Cheers & hth.,

- Alf

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

James Kanze

unread,
Mar 31, 2009, 6:07:34 AM3/31/09
to
On Mar 30, 12:30 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Pavan:

> > Hi Can you clarify following questions regarding uint16_t

> > 1> Does uint16_t is supported by Windows compilers also?

> Presumably the "also" means that you're currently using some
> non-Windows compiler where there is support for uint16_t.

> Type "wikipedia uint16_t" in the Firefox address bar served up
> a list of Google hits; the first was
> <url:http://en.wikipedia.org/wiki/Stdint.h>.

Which isn't exactly the best of what Wikipedia has to offer. To
quote:

Coding Standards for C and C++

This 1999 update to the International Organization for
Standardization's (ISO) was signed off fully in 2004.
[...]

Now, I'm not sure what the author means by "signed off
fully", but <stdint.h> is not part of the C++ standard, even
today (although it will be, and one can expect most C++
compilers to support it). (It would also be interesting to
know where the year 2004 comes from. In C, it has been
official since 1999, in Posix even earlier, and in C++,
probably 2010.) It then goes on to say that "Both C and
C++[citation needed] developers can add #include <stdint.h>
to their source code [...]", which is also highly dubious as
a general statement. (The article also quotes the Posix
standard as the primary source. I believe that the header
did originate in Posix, but the primary source today is the
C standard, and in fact, Posix isn't 100% aligned with the C
standard here---it requires int8_t, etc., indirectly making
Posix impossible to implement on a machine which doesn't
have 8 bit bytes, 2's complement, etc.)

> And that article says "The exact-width types and their
> corresponding ranges are only included in that header if
> they exist for that specific compiler/processor.".

> By the way, if a particular compiler doesn't offer [stdint.h]
> then check out the Boost equivalent.

Which has the same problem: if there is no type of the
corresponding size, the type won't be defined.

> > 2> When I use uint16_t am I always guaranteed that it cannot hold more
> > than 16 bits
> > Eg: uint16_t x = 0xffffffff; // Is it always guaranteed that the value
> > written is only 0xffff
>
> See above. That is, as we said in the old days, RTFM. :)
> Of course, you'd have to find the/a manual first, but it's
> not really that hard (see above).

Except that in this case, the "manual" (IOS/IEC 9899:1999)
isn't available on line. (Or did you mean the manual for
his compiler. That should tell him about the specific
compiler.)

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alf P. Steinbach

unread,
Mar 31, 2009, 6:42:49 AM3/31/09
to
* James Kanze:

Well it's good enough for the OP's question.


>> And that article says "The exact-width types and their
>> corresponding ranges are only included in that header if
>> they exist for that specific compiler/processor.".
>
>> By the way, if a particular compiler doesn't offer [stdint.h]
>> then check out the Boost equivalent.
>
> Which has the same problem: if there is no type of the
> corresponding size, the type won't be defined.

That's not a problem.

It's a feature.

If a compiler doesn't offer [stdint.h] then check out the Boost equivalent.


>>> 2> When I use uint16_t am I always guaranteed that it cannot hold more
>>> than 16 bits
>>> Eg: uint16_t x = 0xffffffff; // Is it always guaranteed that the value
>>> written is only 0xffff
>> See above. That is, as we said in the old days, RTFM. :)
>> Of course, you'd have to find the/a manual first, but it's
>> not really that hard (see above).
>
> Except that in this case, the "manual" (IOS/IEC 9899:1999)
> isn't available on line. (Or did you mean the manual for
> his compiler. That should tell him about the specific
> compiler.)

I meant any documentation. The Wikipedia article is good enough for his purposes.


Cheers,

0 new messages