debate: char vs. byte

[takeshimiya]

..char typedefed as byte or wxByte would be good.

i always used "byte" as typedef'ed "unsigned char"

That's an horror!
In that case, typedef the byte as char
and ubyte as unsigned char.
If not, you'll be against the world.  :lol:

[takeshimiya]

Also, talking about integer types, EVERYONE in the world trying to do portable and optimized use of integers would be using the typedef's provided by the ISO/IEC C++ standard, by including <inttypes.h> (which includes the header <stdint.h> and extends it with additional facilities provided by hosted implementations.)

Example of what EVERYONE should be using:

/* 7.18.1.1  Exact-width integer types */
typedef signed char int8_t;
typedef unsigned char   uint8_t;
typedef short  int16_t;
typedef unsigned short  uint16_t;
typedef int  int32_t;
typedef unsigned   uint32_t;
typedef long long  int64_t;
typedef unsigned long long   uint64_t;

/* 7.18.1.2  Minimum-width integer types */
typedef signed char int_least8_t;
typedef short  int_least16_t;
typedef int  int_least32_t;
...

/*  7.18.1.3  Fastest minimum-width integer types
typedef char int_fast8_t;
typedef short  int_fast16_t;
typedef int  int_fast32_t;
...

And so on. 

[me22]

Also, talking about integer types, EVERYONE in the world trying to do portable and optimized use of integers would be using the typedef's provided by the ISO/IEC C++ standard, by including <inttypes.h> (which includes the header <stdint.h> and extends it with additional facilities provided by hosted implementations.)

Sorry, but neither of those are ISO C++ standard headers.

What people /should/ be using is <boost/cstdint.hpp> if they absolutely need fixed-size types, although the normal types are just fine -- they do have minimum range garuntees.  The best ones, though, are the ones in <boost/integer.hpp>, which let you pick types based on the largest/smallest values you want to store in them.  Certain-size types are no good even for file I/O, though, because of endian issues.

[tiwag]

That's a horror!

?  :shock:

everywhere in the world, since microcontrollers have been developed,
byte's and word's are unsigned and only reflect the size of 8 and 16 bits respectively.
BASTA

don't decompose my old-fashioned view of live   :lol:  !


btw. ubyte - what's that ? some new kind of flu ?

[rickg22]

Please keep the discussion on-topic, people... this was meant to be the unicode thread, not the byte vs. char vs. yards and meters debate. .

[takeshimiya]

Ok, but the problem started because the keyword char is not clear if it's a byte or a character. 

Sorry, but neither of those are ISO C++ standard headers.

Sorry, but they ARE from the ISO C++/C99 Standard library headers.
The fact they come with boost (or some other libraries) is to add support for compilers of the pre-standard era.

From http://en.wikipedia.org/wiki/Standard_C_library
<inttypes.h>: For precise conversion between integer types. (New with C99)
http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
I have the official book from the C/C++ standard and including <inttypes.h> and <stdtypes.h> in the C++ headers it's mandated by C99/C++.
If you don't have the book, just google for inttypes.h and you'll see.

---

everywhere in the world, since microcontrollers have been developed,
byte's and word's are unsigned and only reflect the size of 8 and 16 bits respectively.

everywhere in the world, since microcontrollers have been developed,
used ASCII, and now there is a standard called UNICODE...
The u for unsigned became rather standard for typedef's of unsigned.
It's not what you like or not, you must support the standards (if not, I'll be calling you MS IE :lol:)


Sorry for being a little off-topic, but most of the character (UNICODE) problems are arised by not following the convention/standards.

[me22]

The header <boost/cstdint.hpp> provides the typedef's useful for writing portable code that requires certain integer widths. All typedef's are in namespace boost.

The specifications are based on the ISO/IEC 9899:1999 C Language standard header <stdint.h>.  The 64-bit types required by the C standard are not required in the boost header, and may not be supplied in all implementations, because long long is not [yet] included in the C++ standard.

from http://boost.org/libs/integer/cstdint.htm

ISO C++ : 1998 has normative references to C89, but NOT to C99.

And there's no "official book from the C/C++ standard".  C/C++ doesn't exist.  I don't have a copy of the ISO C++ : 1998 standard myself, but I do have Bjarne's The C++ Programming Language Special Edition which never mentions <stdint.h> or <stdtypes.h> or <inttypes.h>.  Also, if they /were/ in the standard, they'd either be accessable through <cstdint> or <stdint>, to follow the C++ Standard naming conventions.

[takeshimiya]

ISO C++ : 1998 has normative references to C89, but NOT to C99.

In reality it's mandatory in C89, and in C99 also. (Some things have been updated in C99 too).
The next revision of C++ will have almost all of C99.

And there's no "official book from the C/C++ standard". C/C++ doesn't exist. I don't have a copy of the ISO C++ : 1998 standard myself, but I do have Bjarne's The C++ Programming Language Special Edition which never mentions <stdint.h> or <stdtypes.h> or <inttypes.h>.

http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A//www.nirvani.net/docs/ansi_c.pdf&ei=1d4LQ5u4G8DKaKbnrLcI&sig2=b17IrTzIgaM11IcxBzFYyQ
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29237

Also, if they /were/ in the standard, they'd either be accessable through <cstdint> or <stdint>, to follow the C++ Standard naming conventions.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm
Header *<cinttypes>*

Anyways, for writting portable code right now, just use <inttypes.h> from whatever you want (boost, gcc, stlport, your own header, etc).


Well, better to open a new thread if anyone wants to discuss more about this topic (if not, rickg22 will get mad )

[me22]

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29237

If you have it, can you tell me the section number where it's referenced?

Also, if they /were/ in the standard, they'd either be accessable through <cstdint> or <stdint>, to follow the C++ Standard naming conventions.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm
Header *<cinttypes>*

uhh... if you look at the top of that document you'll see:
PROPOSED ADDITIONS TO TR-1 TO IMPROVE
COMPATIBILITY WITH C99
And that paper is NOT one of the ones accepted into tr1.

[takeshimiya]

Thanks for moving the thread

Yes, it's on chapter 7. Library - 7.8 Format conversion of integer types <inttypes.h>
on page 211/554 of the PDF, page 197 of the book.

It's on the C99 Standard but not in the current C++ ISO Standard, and that's why it's very probable it will be in the next revision.

It doesn't sounds very good C being more updated than C++, doesn't it?

Anyways, to make code future-proof and portable, you can include <inttypes.h> right now.
I don't think it would do any harm to not having <cinttypes> right now.
It's not likely you would need to use the std namespace only for some typedef int  int32_t; right?

[zieQ]

Well I suggest not to use stdint.h or inttypes.h since they do not exist in all compiler installation. AFAIK MSVC 6 & 7 do not have any and I would like to compile C::B with MSVC Toolkit one day...

[takeshimiya]

Well, then MSVC 6 & 7 doesn't support C99.

I would suggest doing what boost library do, adding support for the rest of compilers.

I've done something simmilar to this in the past, in a project at sourceforge (called XTypes).
http://sourceforge.net/project/showfiles.php?group_id=96797&package_id=104367&release_id=229086

The important here is to write the code using the intXX_t typedef's.
The header name isn't that important, you can change it later,
but for the integer types, you can't change by doing a search&replace in all the code.

I think this have more importance now that we are in the 32bits/64bits transition period.

[takeshimiya]

me22: I forgot to add the <stdint.h> location in the book:

It's on chapter 7. Library - 7.18 Integer types <stdint.h>
on page 268/554 of the PDF, page 254 of the book.

[zieQ]

I agree here. I've already seen a HAVE_STDINT in some project makefiles so you know if you can use stdint.h or a custom made int definition for thoses typedefs.

[takeshimiya]

  Yep, various compilers, GCC for example defines in the headers
#define _STDINT_H
#define _INTTYPES_H_

So you can #ifdef these.