Regarding the issue of no inverse, I have to admit I haven't read
the proposal but if I were to implement an unbounded integer class I
would probably add an 'inverted' flag to the representation and then
deal with it from there.

---
[ 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                       ]

"msalters" <Michiel.Salters@logicacmg.com> writes:

> "Daniel Kr=FCgler ne Spangenberg wrote:
>> Why should your proposed char iterators be bidirectional?
>
> I asssume because it's slightly easier to parse a number in reverse;

Indeed; I thought it would be more efficient, especially as
(unlike with input iterators) the dynamic memory for the integer
can be allocated immediately at the beginning, instead of growing
it little by little.

On the other hand, the constructor could allow all input
iterators but then choose the best applicable algorithm at
compile time based on std::iterator_traits<T>::iterator_category.
I suppose that would be better.

---
[ 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                       ]

Hello Kalle Olavi Niemitalo,

Kalle Olavi Niemitalo schrieb:

>Indeed; I thought it would be more efficient, especially as
>(unlike with input iterators) the dynamic memory for the integer
>can be allocated immediately at the beginning, instead of growing
>it little by little.
>
I think, this implementation detail should not be presented to the=20
interface user of std::integer.

Consider, that a reasonable allocation strategy of the internal memory=20
of integer (similar to that
of std::vector) can already ensure performant growing.

>On the other hand, the constructor could allow all input
>iterators but then choose the best applicable algorithm at
>compile time based on std::iterator_traits<T>::iterator_category.
>I suppose that would be better.
>
Yes, that is a good idea.

Greetings from Bremen,

Daniel Kr=FCgler


---
[ 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                       ]

Daryle Walker wrote:

> [Apologies if this proposal has been superseded]
>
> I'm looking at
> <http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf>.

A suggestion for the future: include the title of the paper, so folks
don't have to look it up to give easy answers like this one. <g>

It's "Big Integer Library Proposal for C++0x".

As of the most recent WG21 meeting (the week before last) there was no
support for this proposal.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

Pete Becker wrote:
> Daryle Walker wrote:
>
> > [Apologies if this proposal has been superseded]
> >
> > I'm looking at
> >
<http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf>.
>
> A suggestion for the future: include the title of the paper, so folks

> don't have to look it up to give easy answers like this one. <g>
>
> It's "Big Integer Library Proposal for C++0x".
>
> As of the most recent WG21 meeting (the week before last) there was
no
> support for this proposal.

As in, no one showed up and thus no discussion, or was it discussed and
was there an explicit rejection?

I was planning to attend, but couldn't get internal approval. The
original N1692 paper was probably not supported either?

Regards,
Michiel Salters

---
[ 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                       ]

Daryle Walker wrote:
> [Apologies if this proposal has been superseded]

Not yet, but if there is sufficient support for the idea I'll
be happy to make a new version.

> I'm looking at
> <http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf>.
>
> 1.  26.5, point 2
>     Why shouldn't some memory errors be reported with bad_alloc?  A
> memory error could occur even if the result was small.

What's small? I'd say that if the memory allocation fails, the result
is /by definition/ not small - even if it's just 4 bytes.

> 2.  26.5.1
>     What about a "div" function to get the quotient and remainder
> simultaneously?

Good point, my first reaction was to find out where I'd lost it.
I really have no reason not to include it.

>     Since unlimited integers can't have operator ~, you may want to
add
> and_not, or_not, and xor_not functions.  (They act like operators &,
|,
> and ^, but virtually complement their second operand first.)

This sounds a bit strange to me, but I'm not sure yet why.

>     Why aren't the I/O functions generalized for character and traits
> types?
>     Isn't "sgn" the usual computer-math shorthand for the sign
function?
> Should "even" and "odd" be "is_even" and "is_odd"?

Names are of course up to LWG popularity polls, ostream& is shorthand
that
should have been fixed.

>     Is there a reason to include the "factorial" function?  Can it be
> implemented better with inside knowledge of the class?  If not,
exclude
> it unless it gets added to C++ in general (for the built-in numeric
> types).
AFAIK, yes, this can be done better with inside knowledge.

>     Shouldn't the "string" and "char const *" constructors be
explicit?
Probably.
> Shouldn't there be a version for "wchar_t const *" and all versions
of
> "basic_string"?
Same oversight, see the relation between the IOstreams operator and
the string conversions.

> Shouldn't there be an operator ! and a conversion to an unspecified
> Boolean type?
Probably, this is one class that should live up to the "do as int does"
mantra.

> 3.  26.5.4
>     Don't the operators %= need exception warnings for zero-valued
> divisors too?
>     The operators % need exception warnings.
Yes on both.

> 5.  26.5.9
>     Unlike their declarations, these functions are templated for
various
> character and traits types.
>     Neither function respects the various applicable formatting state
> controls.
>     Point 4: "x" is not a complex number.  (Too much copy & paste?)
>     Point 4: "char(x%10)" isn't valid.  It probably should be "char(
'0'
> + x % 10 )".
"Various applicable formatting state" is something I'm not entirely
certain
about.

> 6.  26.5.10
>     I don't think the definition of "pow" makes any sense.  How does
the
> "factorial" function get involved?
Unchecked application of copy/paste keys ;)

> 7.  Rationale
>     I have no problems with rearranging the sections so <integer>
comes
> just after <complex>.
>     Why is unsigned_integer too complex?  It's far simpler to
implement
> (except for subtraction, negation, and decrement) and bitwise
operations
> are more sensical.  You could use it to implement integer.  Anyway,
the
> built-in types have both versions.
This is a case where I'd want more than one opinion

>     Having prefix versions of ++ and -- without postfix versions is
an
> extreme surprise.  Expressions that use an inline postfix need to be
> broken up.  Just let the user eat the cost of the extra copy.
Another point for the LWG to decide IMHO.

>     integer operator <<(long long, size_t) is illegal anyway since
both
> operands are built-ins and the return type isn't considered.
Eh, that is exactly what makes it CWG ;). No reason why they can't make
it a built-in returning a library type. Quite a few why they
/shouldn't/,
but no reason why they /can't/.

>     Should there be a "fma" function?  (It stands for fused
> multiply-add.)

Perhaps, although I've also had a request for more explicit references
to/support for ET implementations. They can get FMA for free.

Regards,
Michiel Salters

---
[ 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                       ]

"msalters" <Michiel.Salters@logicacmg.com> writes:

> What's small? I'd say that if the memory allocation fails, the result
> is /by definition/ not small - even if it's just 4 bytes.

I think it is quite odd to throw an overflow_error from a copy
constructor; if the value was OK for one instance of the class,
then it should also fit in others.

Also, I think it will be easier to recover from the exception
(e.g. retry with a different algorithm that allocates less
memory) if it is a bad_alloc rather than overflow_error.  Or
define a new exception class derived from both?

If an exception occurs in a non-const member function, does the
integer object retain its previous value?


[lib.integer.members] #10: Does the constructor also throw if the
string contains no digits, or if the string contains '+' or '-'
anywhere except at the beginning?

[lib.integer.members] #8-#12: There could also be a constructor
that takes a range of chars delimited by two bidirectional
iterators.  Perhaps even remove the conversion from std::string
altogether.  integer(char const*) should still be kept because it
is so convenient with string literals.

[lib.integer.members] #8-#12: The constructor could take the
numeric base as another parameter (int base =3D 10).  When the base
is a power of 2, the complexity can be O(N) in typical
implementations.  I think it'd be better not to add a constructor
integer(char const*, int base), because it'd be too easy to
assume the second parameter is the length of the string.
Possibly allow base=3D=3D0 with the same meaning as in strtol.

[lib.integer.members] #16: The complexity of the copy assignment
operator seems too high; I'd expect O(N).  (First noted by Daniel
Kr=FCgler: Is N the number of bits in the new value, or the sum or
maximum of bits in both values?)

[lib.integer.members] #20: Likewise, the assignment from long
long should perhaps be O(1) like the corresponding constructor.

[lib.integer.members] #25: Preventing out_of_range also requires
a comparison to integer(LONGLONG_MIN).

[lib.integer.members] #26: I dislike the use of "hex" to mean
base 16 rather than 6, even though iostreams already do this.
The specification could at least say "number of hexadecimal
digits".

[lib.integer.member.arithops] #3, #9: Again, what is the N in O(N)?

[lib.integer.member.arithops] #12: I think -=3D and +=3D should have
the same complexity.

[lib.integer.member.arithops] #22, #25, #29: How do *=3D and /=3D
round or truncate the result?

[lib.integer.member.bitops]: I'd like to note that Common Lisp
has arbitrary-size integers and specifies that bitwise and shift
operations must treat them as binary two's complement.  (The
representation in memory is unspecified.)  This means it can have
the equivalent of operator ~ without inconsistencies.

[lib.integer.iostream]:
> "Various applicable formatting state" is something I'm not
> entirely certain about.

- boolalpha: no effect (not bool).
- dec, hex, oct, showbase: would go along nicely with the base
  parameter to the constructor.
- fixed, scientific, showpoint, precision: no effect (not floating point).
- left, internal, right, width: can't be that hard to implement.
- showpos, uppercase, skipws: easy!
- unitbuf: I'm not sure but it looks like this is automatic if
  you don't access the streambuf directly.
- exceptions: Apparently involves catching the overflow_error
  (or bad_alloc) from internal calculations and setting badbit.
- imbue: I think this would require extending std::locale::num_put
  or defining an entirely new facet.
Anything else?

[lib.integer.member.comp] #1: Because the bitwise member
operators do not change the sign, it seems possible to generate a
negative zero.  The current wording for operator =3D=3D makes the
negative zero compare not equal to a positive zero ("sign" is not
written in the font used for identifiers), with a nasty effect on
operator /=3D.

[lib.integer.funs] #2: Should be "returns false if abs(v) <
(integer(1)<<s)" so that negative integers are handled correctly
and the shift does not overflow right away.

[lib.integer.funs] #13: abs returns an rvalue, so I think the
complexity should be at least O(N) as in the copy constructor.

[lib.integer.funs] #16: I presume sqrt(integer(-1)) throws a
domain_error.

[lib.integer.funs] #24: The number of bits in base should have
some effect on the complexity of pow too.

---
[ 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                       ]

Hello Kalle Olavi Niemitalo,

Kalle Olavi Niemitalo schrieb:

>"msalters" <Michiel.Salters@logicacmg.com> writes:
> =20
>
>Also, I think it will be easier to recover from the exception
>(e.g. retry with a different algorithm that allocates less
>memory) if it is a bad_alloc rather than overflow_error.  Or
>define a new exception class derived from both?
>
I think bad_alloc is fine. The problem with a derived exception class in=20
namespace std
describing something like overflow_error but not being overflow_error=20
would cause more
trouble. One alternative could be an in-class-exception class like

std::integer::failure;

(Similar to std::ios_base::failure)

>[lib.integer.members] #10: Does the constructor also throw if the
>string contains no digits, or if the string contains '+' or '-'
>anywhere except at the beginning?
>
Good point. I think one should use a somewhat more constrained rule as=20
in 22.2.3.1/p. 2.
(which rules out empty digit sequences, multiple sign chars and sign=20
chars at other positions than at
the front)
Something along:

simple_integer ::=3D [plusminus]digits

where plusminus and digits are defined in the quoted paragraph.

>[lib.integer.members] #8-#12: There could also be a constructor
>that takes a range of chars delimited by two bidirectional
>iterators.  Perhaps even remove the conversion from std::string
>altogether.  integer(char const*) should still be kept because it
>is so convenient with string literals.
>
I would not remove the c'tor accepting a std::string. Instead I would=20
propose the following ones
(which are analogous to those provided by std::bitset and=20
boost::dynamic_bitset):

template<class charT, class traits, class Alloc>
explicit integer(
const basic_string<charT,traits,Alloc>& str,
typename basic_string<charT,traits,Alloc>::size_type pos =3D 0,
typename basic_string<charT,traits,Alloc>::size_type n =3D
basic_string<charT,traits,Alloc>::npos,
const Allocator& alloc =3D Allocator());

template <typename CharInputIterator>
integer(CharInputIterator first, CharInputIterator last,=20
const Allocator& alloc =3D Allocator());

(The Allocator might be viewed as an extension of the integer proposal=20
making it to a
class template of typename Allocator)

Why should your proposed char iterators be bidirectional?

>[lib.integer.members] #8-#12: The constructor could take the
>numeric base as another parameter (int base =3D 10).  When the base
>is a power of 2, the complexity can be O(N) in typical
>implementations.  I think it'd be better not to add a constructor
>integer(char const*, int base), because it'd be too easy to
>assume the second parameter is the length of the string.
>Possibly allow base=3D=3D0 with the same meaning as in strtol.
>
Do you imply, that the integer should store the provided base? If so, I=20
would not like this idea,
which would have further implications concerning expectd behaviour in io=20
situations (and maybe others).

Instead of

integer(const char* s, int base);

one could provide:

template <typename CharInputIterator>
integer(CharInputIterator first, CharInputIterator last,  int base);

(modulo Allocator)

or something like

integer(const char* s, base_tag, int base);

where base_tag is some convenient helper type (empty struct or helper enu=
m)

>[lib.integer.members] #25: Preventing out_of_range also requires
>a comparison to integer(LONGLONG_MIN).
>
Yes, correct.

>[lib.integer.member.arithops] #22, #25, #29: How do *=3D and /=3D
>round or truncate the result?
>
Absolutely, this is what I also mentioned concerning the questionable=20
double overloads.
But why #25? Or do you simply mean the general behaviour of these=20
operators? In this
case a reference to 5.6/p. 4 (Or a description equivalent to that)=20
should be fine at least
in case of the operators accepting integral types.

>[lib.integer.member.bitops]: I'd like to note that Common Lisp
>has arbitrary-size integers and specifies that bitwise and shift
>operations must treat them as binary two's complement.  (The
>representation in memory is unspecified.)  This means it can have
>the equivalent of operator ~ without inconsistencies.
>

>- dec, hex, oct, showbase: would go along nicely with the base
>  parameter to the constructor.
>
I always missed ios_base:bin (or something like this) for integral=20
arguments in binary form. But
this is not the right place to complain... (Yes: We no binary literals)

>[lib.integer.member.comp] #1: Because the bitwise member
>operators do not change the sign, it seems possible to generate a
>negative zero.  The current wording for operator =3D=3D makes the
>negative zero compare not equal to a positive zero ("sign" is not
>written in the font used for identifiers), with a nasty effect on
>operator /=3D.
>
Good point! I think that +0 and -0 should behave as equal (As you=20
mentioned, it should correctly
delegate equality on the out-of-class sign/sgn function).

Btw.: I found one further error in the effect description of sign, which=20
currently says:

"Returns: - 1 if v<0 , 0 if v=3D=3D0 , and +1 if v>1"

which should be corrected to say:

"Returns: - 1 if v<0 , 0 if v=3D=3D0 , and +1 if v>0"

Furtheron a question to the experts: Isn't the effect description of=20
sign circular concerning to that
of the relational operators? The proposal obviously does not want to=20
define sign in terms of the
**operators** <, >, and =3D=3D. What is the correct standardese to define=
=20
it? (I could also not find the
effect description of the relation operators of built-in types, 5.9=20
seems not to describe it)

Greetings from Bremen,

Daniel Kr=FCgler


---
[ 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 ne Spangenberg wrote:

> >[lib.integer.members] #8-#12: There could also be a constructor
> >that takes a range of chars delimited by two bidirectional
> >iterators.  Perhaps even remove the conversion from std::string
> >altogether.  integer(char const*) should still be kept because it
> >is so convenient with string literals.

> Why should your proposed char iterators be bidirectional?

I asssume because it's slightly easier to parse a number in reverse;
the basic algorithm is (using reverse_iterators)
integer base = 1;
for( ri = rbegin; ri != rend ; ++ri )
{
  value = base * (*ri);
  base *= 10;
}
Of course, the forward equivalent is
for( i = begin; i != end ; ++i )
{
  value = value * 10 + *i;
}
but I'm not sure if the base*=10 can be optimized better than
value*=10. Both are basically 2 bitshift operations and an
addition, but 10^N has N trailing zeroes that can be ignored.

Regards,
Michiel Salters.


---
[ 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                       ]

[Apologies if this proposal has been superseded]

I'm looking at
<http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf>.

1.  26.5, point 2
    Why shouldn't some memory errors be reported with bad_alloc?  A
memory error could occur even if the result was small.

2.  26.5.1
    What about a "div" function to get the quotient and remainder
simultaneously?
    Since unlimited integers can't have operator ~, you may want to add
and_not, or_not, and xor_not functions.  (They act like operators &, |,
and ^, but virtually complement their second operand first.)
    Why aren't the I/O functions generalized for character and traits
types?
    Isn't "sgn" the usual computer-math shorthand for the sign function?
Should "even" and "odd" be "is_even" and "is_odd"?
    Is there a reason to include the "factorial" function?  Can it be
implemented better with inside knowledge of the class?  If not, exclude
it unless it gets added to C++ in general (for the built-in numeric
types).
    Shouldn't the "string" and "char const *" constructors be explicit?
Therefore, their variants of the assignment operator should be removed.
(You can add named member functions for re-configuration.)  Shouldn't
there be a version for "wchar_t const *" and all versions of
"basic_string"?
    If there's going to be the "XXX_not" family of functions, then
self-modifying versions need to be added to the actual class.
    Shouldn't there be an operator ! and a conversion to an unspecified
Boolean type?

3.  26.5.4
    Don't the operators %= need exception warnings for zero-valued
divisors too?

4.  26.5.7
    The operators % need exception warnings.

5.  26.5.9
    Unlike their declarations, these functions are templated for various
character and traits types.
    Neither function respects the various applicable formatting state
controls.
    Point 4: "x" is not a complex number.  (Too much copy & paste?)
    Point 4: "char(x%10)" isn't valid.  It probably should be "char( '0'
+ x % 10 )".  As it is, you're using code-points 0 through 9, and not
the characters '0' through '9', which aren't garunteed to match.
(Actually, I think they're forbidden to match.  The '\0' character must
have a bit pattern of zero and cannot match any valid character.)

6.  26.5.10
    I don't think the definition of "pow" makes any sense.  How does the
"factorial" function get involved?

7.  Rationale
    I have no problems with rearranging the sections so <integer> comes
just after <complex>.
    Why is unsigned_integer too complex?  It's far simpler to implement
(except for subtraction, negation, and decrement) and bitwise operations
are more sensical.  You could use it to implement integer.  Anyway, the
built-in types have both versions.
    Having prefix versions of ++ and -- without postfix versions is an
extreme surprise.  Expressions that use an inline postfix need to be
broken up.  Just let the user eat the cost of the extra copy.
    integer operator <<(long long, size_t) is illegal anyway since both
operands are built-ins and the return type isn't considered.
    Should there be a "fma" function?  (It stands for fused
multiply-add.)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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                       ]

Hello Daryle Walker,

Daryle Walker schrieb:

>[Apologies if this proposal has been superseded]
>
>I'm looking at
><http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf>.
>
Please have a look at my own posting "Some questions concerning 'big=20
integer' proposal", where I
discuss similar (and further) points.

>    What about a "div" function to get the quotient and remainder
>simultaneously?
>
That would be possible (at least for reasons of consistency), but I see=20
no real advantage. How would you
define its signature and return type? Taking consistency into account=20
one would need something like
integer_div_t, which is nasty at best, using

void div(const integer& numer,  const integer& denom, integer& quot,=20
integer& rem);

would work, but is not the expected one.

Pure C++ style would propably lead to:

std::pair<integer, integer> div(const integer& numer,  const integer&=20
denom);

>    Isn't "sgn" the usual computer-math shorthand for the sign function?
>Should "even" and "odd" be "is_even" and "is_odd"?
>
I support your view concerning is_odd/is_even, and also for sgn versus=20
sign. Actually the full name
would be signum, but sgn is the most popular shorthand. The most=20
important thing is its definition
(which is provided), because there exist definitions, which map its=20
argument to +1 and -1 only (0 is
mostly assigned to +1 in this case)

>    Is there a reason to include the "factorial" function?  Can it be
>implemented better with inside knowledge of the class?  If not, exclude
>it unless it gets added to C++ in general (for the built-in numeric
>types).
>
I tend to agree.

>    Shouldn't the "string" and "char const *" constructors be explicit?
>
Yes.

>Shouldn't there be a version for "wchar_t const *" and all versions of
>"basic_string"?
>
All versions of basic_string: Yes, but why wchar_t const *? Only if this=20
c'tor is added for std::bitset also,
and I do not see any reason for that. The valid characters are all=20
necessarily available as char
representations.

>    If there's going to be the "XXX_not" family of functions, then
>self-modifying versions need to be added to the actual class.
>    Shouldn't there be an operator ! and a conversion to an unspecified
>Boolean type?
>
Absolutely! Otherwise the operator long long is invoked with=20
catastrophic consequences, if this
conversion exceeds the representation range of long long (exception).

>3.  26.5.4
>    Don't the operators %=3D need exception warnings for zero-valued
>divisors too?
>
>4.  26.5.7
>    The operators % need exception warnings.
>
Yes.

>5.  26.5.9
>    Unlike their declarations, these functions are templated for various
>character and traits types.
>
Absolutely (I overlooked that).

>    Neither function respects the various applicable formatting state
>controls.
>    Point 4: "x" is not a complex number.  (Too much copy & paste?)
>    Point 4: "char(x%10)" isn't valid.  It probably should be "char( '0'
>+ x % 10 )".  As it is, you're using code-points 0 through 9, and not
>the characters '0' through '9', which aren't garunteed to match.
>(Actually, I think they're forbidden to match.  The '\0' character must
>have a bit pattern of zero and cannot match any valid character.)
>
To add: I don't think that the current "as if" implementation makes any=20
sense at all (See my posting).

>6.  26.5.10
>    I don't think the definition of "pow" makes any sense.  How does the
>"factorial" function get involved?
>
Absolutely (also overlooked by me).

>    Why is unsigned_integer too complex?  It's far simpler to implement
>(except for subtraction, negation, and decrement) and bitwise operations
>are more sensical.  You could use it to implement integer.  Anyway, the
>built-in types have both versions.
>
I tend to agree.

>    Having prefix versions of ++ and -- without postfix versions is an
>extreme surprise.  Expressions that use an inline postfix need to be
>broken up.  Just let the user eat the cost of the extra copy.
>
Yes.

Please read also my remarks concerning operators taking double values as=20
arguments and my discussion
concerning conversion rules.

Greetings from Bremen,

Daniel Kr=FCgler


---
[ 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                       ]

My quite minor comments on your comments..
Daryle Walker wrote:
> 2.  26.5.1
>     What about a "div" function to get the quotient and remainder
> simultaneously?

I second this, particularily because it's fairly hard to figure out one
without the other, and unlike for built-in types it will be hard for the
compiler to combine the two operations I imagine.

>     Since unlimited integers can't have operator ~, you may want to add
> and_not, or_not, and xor_not functions.  (They act like operators &, |,
> and ^, but virtually complement their second operand first.)

While I can see and_not, surely or_not and xor_not would have the same
problems as just not (that is unless you impose some arbitary bound, the
result would be infinite in length?)

Chris

---
[ 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                       ]