I hear about int32, int64, etc (int128 ?? :) ) in C++

Would it be better to suggest

struct
{
 int a:128;
};

that is, an unnamed structure of bit-fields, to indicate a fixed-width
integer type ?

I think compilers should allow a number of bits at of least
2*sizeof(unsigned long)*CHAR_BIT

What do you think ?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
> I hear about int32, int64, etc (int128 ?? :) ) in C++
>
> Would it be better to suggest
>
> struct
> {
>     int a:128;
> };
>
> that is, an unnamed structure of bit-fields, to indicate a fixed-width
> integer type ?

    Probably too late for that, although Pascal and Ada had such features.

    On a related subject, though, are the names "uint8_t", "uint16_t", etc.
standardized?  Various implementations use similar but not identical
naming conventions for such types of specified size, and that should
be standardized for portability.

    John Nagle
    Animats

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
> Timothy Madden wrote:
> > I hear about int32, int64, etc (int128 ?? :) ) in C++
> >
> > Would it be better to suggest
> >
> > struct
> > {
> >     int a:128;
> > };
> >
> > that is, an unnamed structure of bit-fields, to indicate a fixed-width
> > integer type ?
>
>     Probably too late for that, although Pascal and Ada had such features.
>
>     On a related subject, though, are the names "uint8_t", "uint16_t", etc.
> standardized?  Various implementations use similar but not identical
> naming conventions for such types of specified size, and that should
> be standardized for portability.

Those names are part of the C99 standard. I believe that the
committee's guidelines is to avoid unnecessary incompatibilities with
C, so those names should be used for any C++ types with equivalent
semantics.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
>    Probably too late for that, although Pascal and Ada had such features.

Ada has this much more sensibly organized.
If you need a range of values, you just declare
something like

     a: integer range -100 to 1_000_000;

and let the compiler figure out how to store it.

If you need to conform to some representation
constraint, you additionally say something like

     for a'size use 32;

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
> I hear about int32, int64, etc (int128 ?? :) ) in C++
>
> Would it be better to suggest
>
> struct
> {
>  int a:128;
> };
>
> that is, an unnamed structure of bit-fields, to indicate a fixed-width
> integer type ?

There are two problems I have with this in C/C++ (ignoring how much the
standards suck when it comes to plain integer types in bit-fields with
your example):

a. It exposes the representation. Basically, for signed integer types,
you can only specify the width and the compiler determines what
representation it likes to use. I can't specify a tiny negative range
with a large positive range and treat values outside of that range as
undefined. For a more practical purpose, I can't require it to use 2's
complement and (worst of all) there really is no way to detect the min
value you can store in a signed bit-field, you always have to assume
1's complement or signed-magnitude for standard conformance.

b. It requires layout compatible structs to alias each other. I had an
idea to abuse the register keyword:

struct A {
 register int a;
};

struct B {
 register int a;
}:

struct C {
 int a;
};

struct D {
 int a;
};

And make:
- A isn't compatible with anything except itself, ditto for B
- C and D are considered layout compatible with each other

to take advantage of the ancient rule that register variables couldn't
have their address taken so there would be no possible way to take the
address of the variable a without evil tricks.

I think this would be much more flexible and simpler than trying to get
strong typedefs in the standard.

> I think compilers should allow a number of bits at of least
> 2*sizeof(unsigned long)*CHAR_BIT
>
> What do you think ?

I'd find it a lot more useful if it was at least
log2((UINTMAX_MAX+1)*(UINTMAX_MAX+1))+1 value bits. The log2(...) so I
can multiply 2 (u)intmax_t integers, the +1 so I can also add a sign
bit on top of this.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]