 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Timothy Madden Guest
|
Posted: Wed Mar 08, 2006 4:06 am Post subject: Use bit fields for sized integer types |
|
|
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 ] |
|
| Back to top |
|
 |
John Nagle Guest
|
Posted: Wed Mar 08, 2006 3:25 pm Post subject: Re: Use bit fields for sized integer types |
|
|
Timothy Madden wrote:
| Quote: | 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 ] |
|
| Back to top |
|
 |
Guest
|
Posted: Wed Mar 08, 2006 5:43 pm Post subject: Re: Use bit fields for sized integer types |
|
|
John Nagle wrote:
| Quote: | 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 ] |
|
| Back to top |
|
 |
Hyman Rosen Guest
|
Posted: Thu Mar 09, 2006 5:06 am Post subject: Re: Use bit fields for sized integer types |
|
|
John Nagle wrote:
| Quote: | 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 ] |
|
| Back to top |
|
 |
Me Guest
|
Posted: Fri Mar 10, 2006 6:33 am Post subject: Re: Use bit fields for sized integer types |
|
|
Timothy Madden wrote:
| Quote: | 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.
| Quote: | 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 ] |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|