Real good reason. I am now ashamed of my original (a bit stupid)
suggestion.
Returning such a beast will give huge problems - and not just with
the syntax.

However I will try to defend my suggestion within the bitfield.
(Until someone gives me the right counter-argument =)  )

struct BitFieldLongInt
{
  unsigned int x : 256;
};

Now - this would still make some sense. Math is done the "expected
way".
But the "type of" x can not be used in declarations and
1) A functions given this argument will get a truncated value.
2) A function returning this argument will return a truncated value.
(Both could (/should) give a warning)
It can be casted to int without a warning.

The only way to pass on a higher int-value is with the class.

Now I have noticed that this is (a little) ugly, but compared to what
exists I consider it as an improvement. Not just for the extension
int-range ( it could also  be the proposed "bit int"), but consider
the following

#define INT_BIT_SIZE 17
struct BitFieldStruct
{
  unsigned int y :  INT_BIT_SIZE;
};

Is this C++ - Will it compile ?

The answer is most likely yes - but it does not have to.

This will compile if (and only if)  INT_BIT_SIZE <=
sizeof(int)*CHAR_BIT.
(So it is only guaranteed to work with INT_BIT_SIZE<17)

However it might work and make sense with a value on 22 (or
above)......
(Actually 22 is used as an example in the "The C++ programming
language" by Bjarne Stroustrup - C.8.1 - however it need not to
compile on all compilers - or?)

It is a non-portable behavior - and it is not "just" a change on
runtime overflow, but a change on what is C++ on different compilers
..

Thorbj   rn Martsum
-----------------------------------

PS:
To comment some of the other reactions to my suggestion I would like to
mention that

The compiler can generally optimize a fixed intsize far better than
anyone can write C++-code.  On most (every?) architectures it can do
sum (adc) , subtraction (sbc), shift and a lot more with use of a
carry-flag.
(The operations are of couse more expensive than the once with a simple
int)

I had only heard about the infinite int - where I was afraid of
performance (if it would work with loops/lots of branching). This would
(also) give me what I
was looking for, but still not change the problem with bitfield. (I
have also been looking at bitset, but I need(ed) addition and
subtraction.)


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Thorbjorn,
An infinite precision integer automatically adjusts its length,
which is to be preferred above fixed length with overflows.
Of course it is about as fast as a fixed length integer.
The infinite precision integer in C++ standard library was proposed, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1718.pdf
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf
however as far as I know it was rejected.
But in the meantime Gnu Multiple Precision Arithmetic Library
GMP (see http://www.swox.com/gmp/) with infinite precision integer
has been included in the glibc library of the Gnu C/C++ compiler,
see ftp://ftp.gnu.org/gnu/glibc/
GMP has a C++ wrapper of its infinite precision integer.


<tmartsum@gmail.com> wrote in message
news:1127732586.999937.110650@g47g2000cwa.googlegroups.com...
> At http://www.research.att.com/~bs/evol-issues.html there is a
> suggestion on an
> an infinite precision integer class. (ES082)
>
> Probably infinite is a "wrong word" ? Because what is most needed is
> a fixed precision. (Compilers can create more optimized code for a
> fixed length).
>
> But why not just make a little extension to the language.
> Is there a reason NOT to allow code like
>
> int main()
> {
>   unsigned int x : 256;
>   // Should mean x is an unsigned integer of 256-bits
> }
>
> I know there are something to consider e.g.
> Should it provide alignment like the bitfield ?
> (My opinion says no - but I guess that is not interesting -
> there are probably good reasons why it should not be allowed ?)
>
> /Thorbj=F8rn
>
>
> ---
> [ 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.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

At http://www.research.att.com/~bs/evol-issues.html there is a
suggestion on an
an infinite precision integer class. (ES082)

Probably infinite is a "wrong word" ? Because what is most needed is
a fixed precision. (Compilers can create more optimized code for a
fixed length).

But why not just make a little extension to the language.
Is there a reason NOT to allow code like

int main()
{
  unsigned int x : 256;
  // Should mean x is an unsigned integer of 256-bits
}

I know there are something to consider e.g.
Should it provide alignment like the bitfield ?
(My opinion says no - but I guess that is not interesting -
there are probably good reasons why it should not be allowed ?)

/Thorbj   rn


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

tmartsum@gmail.com wrote:

> int main()
> {
>   unsigned int x : 256;
>   // Should mean x is an unsigned integer of 256-bits
> }

Let's examine this syntax a little further.  How would we declare a
function returning a 256-bit unsigned integer?  The "natural" syntax
would seem to be

  unsigned int fn() : 256;

How about declaring an array of 256-bit integers?  The "natural" syntax
would again be

  unsigned int array[32] : 256;

Neither are exactly intuitive.

If this syntax were adopted, no doubt someone would propose a standard
template alias (assuming they happen)

  namespace std {
    template <size_t N>
      using fixed_width_int = int : N; // or whatever the syntax would
be
  }

and then use that instead:

  std::fixed_width_int<256> fn();
  std::fixed_width_int<256> array[32];

--
Richard Smith

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Why change the language when something can be done just as well (or
better, as you can choose whether to implement things like divide by
zero checks and error behaviours) in a user defined type?

Tony

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]