Paul Hamilton wrote:

> In article <350D5D85.E19B7522@ArtQuest.fr>, hh@ArtQuest.fr,
> holin@mathp7.jussieu.fr wrote:
>
> > Paul Hamilton wrote:
> >
> > [SNIP]
> >
> > > This get's mentioned quite often around C++, but the reality is that
> > > passing structs between machines is a really bad idea.
> >
> >  Passing data (such as graphic files) between machines is customary and
> > necessary. Thankfully, M$ does not dominate to such an extant that only one
> > platform needs to be considered.
> >
>
> Thankfully, there are standard libraries such as QuickTime, LoadBitmap(),
> GIF, PNG, TIFF, JPEG libraries that do all of the dirty work for you as to
> displaying graphics.

I guess it is worth mentioning that "standard libraries" do not always exist, or
are unsuitable for some specific task. For a concrete example, a substantial part
of my work deals with the creation of TIFF files manipulation programs for a
company selling solutions to the pre-press world. The files are bulky, and need
to be processed as speedily as possible, and sometimes in unusual formats
(TIFF/IT supports HCRLE compression, for instance, which is not widely
supported). Some of the manipulations (such as scaling, dithering, color
manipulation...), have to be rewritten from the bottom-up, and this is part of my
job. So I want to have the greatest amount of *language* support at my disposal.
In a sense, I write these "standard libraries" you refer to, but even if I were
not somebody else would be, and would be faced with the same kind of problems.
You just can't hide the problem under a rug...

> This is one example where standard data type sizes would be useless, since
> all graphics programs take the file on the disk, interpret it at a low
> level (as an opcode stream in the case of most of these), and then pack it
> into a machine-dependant chunk of data like a PixMap or HBITMAP etc.

Well, no. I have to do the low level stuff. And again, even if somebody else did
it, he would be faced with the same kind of problems.

Furthermore, for the algorithms involved (say scaling), everything is machine
independent (as far as the standard allows). It just has to be that way.


> TIFF for example goes out of it's way to be explicit in byte ordering.
> Being able to lay a struct over the top of some part of a TIFF would not
> buy you very much.
>
> Maybe all of the bit data is reversed, so every time you blit you would
> have to unreverse!

Displaying is not the be-all and end-all of graphic files. And yes, one has to
take care of endianness. I thankfully have not the need to support wacky
bit-orders (that's a compromise to speed), but even if I did, I would be back to
square one (known  bit-size types) after that stage, so that I can further
process the data.


> You get the idea.
>
> Paul.


So, to sum it up, yes, I truly believe known bit-size types should be part of the
standard (and let's not forget those "long long"s :-) ).

        Hubert Holin
        holin@mathp7.jussieu.fr
        hh@ArtQuest.fr



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > > typedef UINT32  ...;    // an unsigned integer of _exactly_ 32 bits
> > > typedef SINT32  ...;    // a signed integer of _exactly_ 32 bits
> > > typedef uint32  ...;    // an unsigned integer of _at_least_ 32 bits
> > > typedef sint32  ...;    // a signed integer of _at_least_ 32 bits
> > >
> > > Of course, there are UINT16, SINT8, uint64, etc., as well.  I've also
> > > defined FLOAT32, FLOAT64, float32, and float64 types using the same
> > > conventions.
>
> Except that his UINT16, etc. are not structs, but basic data types.
> Of course, there is still the problem of byte order, signed representation,
> and what to do if bytes aren't 8 bits.  While the latter two are pretty
> exotic (although implementations exist), byte order can't be ignored.

Tell me about it!  Endian problems are the biggest pain in the ass for
cross-platform development.  I no longer care who wins the battle.  I
just want it over!  <tired smile>


> Of course, such definitions for float's are completely useless, given
> the wide variation in floating point formats.

How different are they.  Most machines use the (one of?) IEEE spec.  How
much do the bit patters differ across architectures?


> > Relying on bit/byte size, or even the fact that structures will actually
> > stay the same size, with members in the same positions between revs of
> > compilers/code bases is not realistic.
>
> I think that you can probably rely on the things determined by hardware,
> like the representation of negative numbers, or the number of bits in
> a byte, not changing.  That's about it, though.

Compilers are pretty standard on this.  They generally pack things together
as tightly as possible within the restrictions of alignment.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
  `My name is Ozymandias, King of Kings: Look upon my works, ye Mighty, and
  despair!'  Nothing besides remains.  Round the decay of that colossal wreck,
  boundless and bare, the lone and level sands stretch far away.   -- Shelly
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

|Is there anything in the the ANSI C++ spec that provides for datatypes of
|known bit sizes?
|
|If not, could such a thing be added?  Such a thing is really needed when
|making data structures that can be moved across machines.

Personally, I would rephrase that as `such a thing is rarely
needed', etc., but that's likely to start a philosophical
argument. :-)

To stick to the question, as near as I can see, the draft standard
does not include such things, but the C9X draft for the next
revision of the C Standard does, and it may eventually get folded
into C++.

The C9X proposal adds a new header, inttypes.h, that typedefs
at least, fastest at least, and exact sized integers of various
sizes, as well as largest integer types, and types for pointer/int
conversion.  There are also macros that are defined that can be
used to check if the required type exists.  Also, if my reading of
the draft is correct, there is still the caveat that integer types
are still allowed to have `holes' so the exact sized types may
not actually be the size you expect, they just have to _behave_
as if they are.
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Brian White wrote:
>
> Is there anything in the the ANSI C++ spec that provides for datatypes of
> known bit sizes?
>
> If not, could such a thing be added?  Such a thing is really needed when
> making data structures that can be moved across machines.
>
> In the past, I've used the following conventions and found they work
> very well.
>
> typedef UINT32  ...;    // an unsigned integer of _exactly_ 32 bits
> typedef SINT32  ...;    // a signed integer of _exactly_ 32 bits
> typedef uint32  ...;    // an unsigned integer of _at_least_ 32 bits
> typedef sint32  ...;    // a signed integer of _at_least_ 32 bits
>
> The "uint32" would be defined as a the type optimial for that compiler
> that was a minimum of 32 bits long.  A "uint8" would probably be an
> "unsigned char" while "sint16" and "sint32" would just be "int" (on a
> 32-bit machine, of course).
>
> Of course, there are UINT16, SINT8, uint64, etc., as well.  I've also
> defined FLOAT32, FLOAT64, float32, and float64 types using the same
> conventions.

The new <inttypes.h> standard header for C9X will include things like
this (but only for integers). The naming is a little clumsy:

int8_t  exactly 8 bits
uint_least16_t at least 16 bits
int_fast32_t Fastest integral type big enough to hold 32 bit integers
intmax_t Largest integer type
intptr_t A type large enough to safely store and return a void *

There are corresponding macros for each type:
INT64_MAX
INT_LEAST_32_MIN
UINT16_C() expands its argument into a integer constant of the
  specified type, by adding suffixes as necessary.
PRIiFAST64 printf() format string
SCNd16  scanf() format string

Only the 8, 16, 32, and 64 sizes are required, and all exact and pointer
types are optional. You can test for the existence of the optional types
by using #ifdef of a corresponding macro. The C9X standard has reserved
the entire [u]int*_t name space, plus the corresponding macro names for
future library extensions.

It is probably too late add these to the C++ standard, but I think you
will find that most compiler makers who bundle together C and C++
compilers will provide these types as extensions in the C++ compiler.
<inttypes> almost certainly will be considered for inclusion in the
following C++ standard, many years from now.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35084BDC.4108978E@verisim.com>, Brian White
<bcwhite@verisim.com> wrote:

> Is there anything in the the ANSI C++ spec that provides for datatypes of
> known bit sizes?
>
> If not, could such a thing be added?  Such a thing is really needed when
> making data structures that can be moved across machines.
>
> In the past, I've used the following conventions and found they work
> very well.
>
> typedef UINT32  ...;    // an unsigned integer of _exactly_ 32 bits
> typedef SINT32  ...;    // a signed integer of _exactly_ 32 bits
> typedef uint32  ...;    // an unsigned integer of _at_least_ 32 bits
> typedef sint32  ...;    // a signed integer of _at_least_ 32 bits
>
> The "uint32" would be defined as a the type optimial for that compiler
> that was a minimum of 32 bits long.  A "uint8" would probably be an
> "unsigned char" while "sint16" and "sint32" would just be "int" (on a
> 32-bit machine, of course).
>
> Of course, there are UINT16, SINT8, uint64, etc., as well.  I've also
> defined FLOAT32, FLOAT64, float32, and float64 types using the same
> conventions.
>

This get's mentioned quite often around C++, but the reality is that
passing structs between machines is a really bad idea.

The best way to achieve compatibility is to override your objects with
serialize methods (or use streams) to put and get the data.

Relying on bit/byte size, or even the fact that structures will actually
stay the same size, with members in the same positions between revs of
compilers/code bases is not realistic.

Paul.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35097536.2781@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
>Brian White wrote:
>>
>> Is there anything in the the ANSI C++ spec that provides for datatypes of
>> known bit sizes?

The following declarations can be used in ANSI C++ code (I think - please
correct me if I've made a mistake!) to get an int of a known size.  To get
a signed integral type of exactly 16 bits, use
  sized_int<16,true>::int_t
and to get an unsigned integral type of at least 19 bits, use
  sized_int<19,false>::int_min_t

Code follows:
#include <climits>

template <size_t TSizeInBits, bool TSigned>
struct sized_int
{ typedef sized_int<TSizeInBits+1, TSigned>::int_min_t int_min_t; };

// Specialize for a very large value (max size_t) to ensure that
// when trying to get an int_min_t larger than the largest int type
// on this machine, the recursion ends.  In practice, it will end
// much earlier with a compiler error due to template recursion limits.
template<bool TSigned>
struct sized_int<ULONG_MAX, TSigned> {};


#define SPECIALIZE_SIZED_INT(TYPE) \
template<> struct sized_int<sizeof(signed TYPE) * CHAR_BIT, true> \
 { typedef signed TYPE int_t; typedef signed TYPE int_min_t; }; \
template<> struct sized_int<sizeof(unsigned TYPE) * CHAR_BIT, false> \
 { typedef unsigned TYPE int_t; typedef unsigned TYPE int_min_t; }

// Specialize for char
SPECIALIZE_SIZED_INT(char);

// Specialize for short if it's bigger than char
#if (USHRT_MAX > UCHAR_MAX)
 SPECIALIZE_SIZED_INT(short);
#endif

// Specialize for int if it's bigger than short
#if (UINT_MAX > USHRT_MAX)
 SPECIALIZE_SIZED_INT(int);
#endif

// Specialize for long if it's bigger than int
#if (ULONG_MAX > UINT_MAX)
 SPECIALIZE_SIZED_INT(long);
#endif

// Specialize for long long if it exists and it's bigger than int
#if defined(ULONGLONG_MAX) && (ULONGLONG_MAX > ULONG_MAX)
 SPECIALIZE_SIZED_INT(long long);
#endif

#undef SPECIALIZE_SIZED_INT

- Marc
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <paul-1303981134270001@206.169.118.19>,
  paul@mbed.com (Paul Hamilton) wrote:
>
> In article <35084BDC.4108978E@verisim.com>, Brian White
> <bcwhite@verisim.com> wrote:
>
> > Is there anything in the the ANSI C++ spec that provides for datatype=
s of
> > known bit sizes?
> >
> > If not, could such a thing be added?  Such a thing is really needed w=
hen
> > making data structures that can be moved across machines.
> >
> > In the past, I've used the following conventions and found they work
> > very well.
> >
> > typedef UINT32  ...;    // an unsigned integer of _exactly_ 32 bits
> > typedef SINT32  ...;    // a signed integer of _exactly_ 32 bits
> > typedef uint32  ...;    // an unsigned integer of _at_least_ 32 bits
> > typedef sint32  ...;    // a signed integer of _at_least_ 32 bits
> >
> > The "uint32" would be defined as a the type optimial for that compile=
r
> > that was a minimum of 32 bits long.  A "uint8" would probably be an
> > "unsigned char" while "sint16" and "sint32" would just be "int" (on a
> > 32-bit machine, of course).
> >
> > Of course, there are UINT16, SINT8, uint64, etc., as well.  I've also
> > defined FLOAT32, FLOAT64, float32, and float64 types using the same
> > conventions.
> >
>
> This get's mentioned quite often around C++, but the reality is that
> passing structs between machines is a really bad idea.

Except that his UINT16, etc. are not structs, but basic data types.
Of course, there is still the problem of byte order, signed representatio=
n,
and what to do if bytes aren't 8 bits.  While the latter two are pretty
exotic (although implementations exist), byte order can't be ignored.

Of course, such definitions for float's are completely useless, given
the wide variation in floating point formats.

> The best way to achieve compatibility is to override your objects with
> serialize methods (or use streams) to put and get the data.

Again: how do you override a function on int.

> Relying on bit/byte size, or even the fact that structures will actuall=
y
> stay the same size, with members in the same positions between revs of
> compilers/code bases is not realistic.

I think that you can probably rely on the things determined by hardware,
like the representation of negative numbers, or the number of bits in
a byte, not changing.  That's about it, though.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Hamilton wrote:

[SNIP]

> This get's mentioned quite often around C++, but the reality is that
> passing structs between machines is a really bad idea.

 Passing data (such as graphic files) between machines is customary and
necessary. Thankfully, M$ does not dominate to such an extant that only one
platform needs to be considered.

[SNIP]

> Relying on bit/byte size, or even the fact that structures will actually
> stay the same size, with members in the same positions between revs of
> compilers/code bases is not realistic.

Knowing the bit-size of your data is an appreciated help when you do
integer-based computations (it insures bound checks, for instance).

C++ does need this feature (and an officialization of 64 bits "long long"s...).

        Hubert Holin
        holin@mathp7.jussieu.fr
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > Is there anything in the the ANSI C++ spec that provides for datatypes of
> > known bit sizes?
>
> This get's mentioned quite often around C++, but the reality is that
> passing structs between machines is a really bad idea.
>
> The best way to achieve compatibility is to override your objects with
> serialize methods (or use streams) to put and get the data.

Unfortunately, this doesn't help unless you convert everything down to
the byte level.  Writing out a sequence of ints will still break if
both machines don't have the same sizeof(int).  If I have to do everything
at the byte-level, what's the point of having any other types in the
first place?


> Relying on bit/byte size, or even the fact that structures will actually
> stay the same size, with members in the same positions between revs of
> compilers/code bases is not realistic.

And therein lies another problem.  Structures get written out to disk or
passed over a network so often that it would be very useful to have some
way of mapping these two in a way that is guaranteed not to change.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
        Stress:  The condition caused by resisiting the desire to choke
            the life out of some idiot who desperately deserves it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <350D5D85.E19B7522@ArtQuest.fr>, hh@ArtQuest.fr,
holin@mathp7.jussieu.fr wrote:

> Paul Hamilton wrote:
>
> [SNIP]
>
> > This get's mentioned quite often around C++, but the reality is that
> > passing structs between machines is a really bad idea.
>
>  Passing data (such as graphic files) between machines is customary and
> necessary. Thankfully, M$ does not dominate to such an extant that only one
> platform needs to be considered.
>

Thankfully, there are standard libraries such as QuickTime, LoadBitmap(),
GIF, PNG, TIFF, JPEG libraries that do all of the dirty work for you as to
displaying graphics.

This is one example where standard data type sizes would be useless, since
all graphics programs take the file on the disk, interpret it at a low
level (as an opcode stream in the case of most of these), and then pack it
into a machine-dependant chunk of data like a PixMap or HBITMAP etc.

TIFF for example goes out of it's way to be explicit in byte ordering.
Being able to lay a struct over the top of some part of a TIFF would not
buy you very much.

Maybe all of the bit data is reversed, so every time you blit you would
have to unreverse!

You get the idea.

Paul.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is there anything in the the ANSI C++ spec that provides for datatypes of
known bit sizes?

If not, could such a thing be added?  Such a thing is really needed when
making data structures that can be moved across machines.

In the past, I've used the following conventions and found they work
very well.

typedef UINT32 ...; // an unsigned integer of _exactly_ 32 bits
typedef SINT32 ...; // a signed integer of _exactly_ 32 bits
typedef uint32 ...; // an unsigned integer of _at_least_ 32 bits
typedef sint32 ...; // a signed integer of _at_least_ 32 bits

The "uint32" would be defined as a the type optimial for that compiler
that was a minimum of 32 bits long.  A "uint8" would probably be an
"unsigned char" while "sint16" and "sint32" would just be "int" (on a
32-bit machine, of course).

Of course, there are UINT16, SINT8, uint64, etc., as well.  I've also
defined FLOAT32, FLOAT64, float32, and float64 types using the same
conventions.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
Seize the moment!  Live now.  Make "now" always the most important time. -- JLP
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]