There is an article in a recent C++ report about template
metaprogramming that allows you to define types like:

  Integer<16> x;
  Integer<20> y;

These are ensured to give you the smallest data type capable
of holding the appropriate size, and it's selected at compile
time due to some recursive template magic.

I think it is in one of the past two or three issues. I read
the articles well before they're published and often lose
track...

--
Tim
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Tim Ottinger wrote:
>
> There is an article in a recent C++ report about template
> metaprogramming that allows you to define types like:
>
>   Integer<16> x;
>   Integer<20> y;
>
> These are ensured to give you the smallest data type capable
> of holding the appropriate size, and it's selected at compile
> time due to some recursive template magic.

It was something similar that prompted my question about template
typedefs the other day. I can't see any way of doing the above exactly
(unless you can live with Integer<16> being a user-defined type that
behaves something like an integer, rather than actually being one of the
built-in integer types); instead I used typedefs nested within a
template class, so if you want the smallest integer with at least 16
bits, you use Int<16>::Least.

Here's what I ended up with (it works on EGCS 1.0; if an older compiler
has trouble with it, try removing the word "typename" and maybe the
dummy definitions of the exact types):


// Integers of specified sizes
// #include <integer_bits.hpp>
// Ross Smith 5-Jan-98

// Int<N>::Exact, Int<N>::ExactU
//   -- Signed and unsigned integers of exactly N bits, if available.
// Int<N>::Fast, Int<N>::FastU
//   -- The fastest signed and unsigned integers with at least N bits
//      (the implementation assumes that int is the fastest integer
//      type).
// Int<N>::Least, Int<N>::LeastU
//   -- The smallest signed and unsigned integers with at least N bits.

#ifndef __INTEGER_BITS_HPP__
#define __INTEGER_BITS_HPP__

#include <climits>

template <unsigned N> class Int {
  private:
    // Dummy definitions
    typedef int Exact;
    typedef int ExactU;
  public:
    typedef typename Int<N + 1>::Fast Fast;
    typedef typename Int<N + 1>::FastU FastU;
    typedef typename Int<N + 1>::Least Least;
    typedef typename Int<N + 1>::LeastU LeastU;
};

class Int<CHAR_BIT> {
  public:
    typedef signed char Exact;
    typedef unsigned char ExactU;
    typedef int Fast;
    typedef unsigned FastU;
    typedef signed char Least;
    typedef unsigned char LeastU;
};

#if USHRT_MAX > UCHAR_MAX
class Int<CHAR_BIT * sizeof(short)> {
  public:
    typedef short Exact;
    typedef unsigned short ExactU;
    typedef int Fast;
    typedef unsigned FastU;
    typedef short Least;
    typedef unsigned short LeastU;
};
#endif

#if UINT_MAX > USHRT_MAX
class Int<CHAR_BIT * sizeof(int)> {
  public:
    typedef int Exact;
    typedef unsigned ExactU;
    typedef int Fast;
    typedef unsigned FastU;
    typedef int Least;
    typedef unsigned LeastU;
};
#endif

#if ULONG_MAX > UINT_MAX
class Int<CHAR_BIT * sizeof(long)> {
  public:
    typedef long Exact;
    typedef unsigned long ExactU;
    typedef long Fast;
    typedef unsigned long FastU;
    typedef long Least;
    typedef unsigned long  LeastU;
};
#endif

#endif


--
Ross Smith (Wellington, New Zealand) ...... <mailto:alien@netlink.co.nz>
      "While I'd like to claim that it was a bitter and satirical
      attack upon the mindless brutalities of war, it was really
      just plain bloody violent..."                 -- Alan Moore
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

The basic types c++ inherited from c is a mess,we got
signed,unsigned,short,long,int,float,double to make thousands of
combinations.(now I hear a "long long" is going to be added,what a
mess!),yet  we don't have a portable way to get a 32-bit int! now everyone
has his own set of typedef for some basic types:
byte,BYTE,uchar,ushort,int16,uint16,int32,WORD,DWORD,UINT...
we are lazy to write "unsigned short" so we invent "ushort", we want our int
to be 32 bit so we invent int32(actually int32 doen't guarentee
portablity,you still need to change the typedef).but why on earth we don't
get a standard on it? actually we only need several basic types:
char,byte 8 bit,
sshort,ushort:16bit,
sint,uint: 32bit,
slong,ulong 64 bit.
int,unsigned:machine dependant.

there may be better names for them,but the key point is:
1) one short identifier for the type name,we don't need signed/unsigned
short/long modifier(we can't say "unsigned A " or "long A" if A is a
class,can we? so this make the language more coherent)
2) size of each type should be specified by the
standard,ie.16bit,32bit,etc.so we don't worry about portability

At least there should have a standard header file to typedef these types if
we can not make them the basic type.C++ already have things as complex as
template and exception,things as weird as 'mutable', it's a shame lacking
such trivial and basic item.
I'm sure most programer will be glad to see these types added.

actually these suggestion apply to c as well,but i'm a c++ programmer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 02 Jan 1998 14:13:02 PST, "jack" <jack-zeng@usa.net> wrote:

>The basic types c++ inherited from c is a mess,we got
>signed,unsigned,short,long,int,float,double to make thousands of
>combinations.(now I hear a "long long" is going to be added,what a
>mess!),yet  we don't have a portable way to get a 32-bit int!

Nor do we have a portable way to get an 18-bit or a 36-bit simple
variable. If you are working on a machine whose word size is not a
power of 2, 32-bit variables are not very interesting, unless you are
matching an external format. In that case you can probably use bit
fields.

C and C++ provide various integer sizes of a guaranteed minimum size.
The actual size will be chosen by the implementer, usually a size
which makes for efficient programs in the usual case.

> now everyone
>has his own set of typedef for some basic types:
>byte,BYTE,uchar,ushort,int16,uint16,int32,WORD,DWORD,UINT...

And you will need those for portable programming. (To some
programmers, "portable" means "works on both Windows 3.1 and Windows
95". I use "portable" to mean a wide variety of platforms.) Any
portable program will need a set of typedefs and other special
definitions that are customized for each platform. It isn't hard to
add a few extra ones -- uchar, int16, etc -- that your program needs.

I don't mean to be pedantic. Most popular systems today have a word
size that is a multiple of 16 bits. Many standard external formats
(e.g. for networking) have fields that are multiples of 8 bits. So it
would be reasonable to have a set of standard definitions to match.

>At least there should have a standard header file to typedef these types ...

The emerging new standard for C contains a standard header
(<inttypes.h> if I remember correctly) with predefined types of exact
as well as minimum bit sizes. It took years of wrangling (some
wrangling still in progress) to figure out what those ought to be. And
there is no requirement that a given system will actually implement
all of them -- it might not be reasonable to implement, for example, a
16-bit type on a 36-bit machine.

When the new C standard is complete, I would expect C++
implementations to add a version of <inttypes.h> for compatibility.
When the C++ standard comes up for revision, the added features of the
C standard will be included in it. By then we will have the happy
circumstance of ratifying existing practice, instead of inventing new
things.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 02 Jan 1998 14:13:02 PST, "jack" <jack-zeng@usa.net> wrote:
>...
>At least there should have a standard header file to typedef these types if
>we can not make them the basic type.C++ already have things as complex as
>template and exception,things as weird as 'mutable', it's a shame lacking
>such trivial and basic item.
>I'm sure most programer will be glad to see these types added.
>...

I believe that the upcoming C9x standard has such a header-
inttypes.h- that has typedefs such as int16_t, uint16_t etc.

More details can be found at
ftp://ftp.dmk.com/DMK/sc22wg14

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]