C++Talk.NET

tmartsum@gmail.com · Guest

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 ]

Daniel Krügler · Guest

Hello Thorbjørn,

[email]tmartsum (AT) gmail (DOT) com[/email] wrote:

richard@ex-parrot.com · Guest

[email]tmartsum (AT) gmail (DOT) com[/email] wrote:

Tony Delroy · Guest

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 ]

tmartsum · Guest

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 ]

Maarten Kronenburg · Guest

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 (AT) gmail (DOT) com> wrote