allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0301211416.524b0723@posting.google.com>...
>danielgutson@hotmail.com (danielgutson@hotmail.com) wrote
> > I'd also like your feedback about supporting generic-length literals,
> > as the base for generic-length integral numbers.
>  [snip]
> > This proposal, together with the 'type modifier template parameter',
> > would be the basic features for generic-length numeric classes as
> > library implementations.
>
>It seems to me that this proposal would BE the basics of an
>generic-length numeric class. You almost wouldn't need a library
>implementation, if you could do this.
>
>However, note that you can create a generic-length numeric library
>class using the existing language. It would allow you to use an
>integer type in a manner almost completely analagous to ints and longs,
>except that literals would have to be handled differently.
>
> > MySuperInt x(987987987987987987987987987987987987987987987987987);
>would change to
>   MySuperInt x("987987987987987987987987987987987987987987987987987");
>

I have many comments; I'd like to enum them first

1) About using string literals
2) About being this the only proposal for generic-length integers
3) Why would a library implementation be 'complementary' to this (and the
others I'll mention) proposals
----

1) String literals. Three months ago, I was writing this proposal in the
form of paper. I found lots of both C and C++ libraries for covering this
purpose.
Mi final motivation is a template integer type that receives the length as
template parameter, and a 'replacing typedef' (see later, in point 2) for
the platform's native integers (i.e., a mapping for GenericInt<4> to int).
So I wrote a 'prototype' accepting those literals as initializers.
But, considering this is just a dependant for a complete support (see next
part pls), let's agree that this can perfectly be a compiler commodity, for
the following reasons:
  - different numeric literals formats may appear (0x.., decimal, binary,
whatever) and the abstraction is provided
  - conversion is done in compile time (instead of the parsing of the
string)
  - the compiler already has the mechanisms for converting 'constant
expression literals' to integers; this is just making them available to
generic length (as far as the literals are text to be parsed by the
compiler, so why to do it 'by hand'?)
  - different conversion could be applied to different types (many integral
types can appear, even by standarization or by user-definition, see the
template argument of Literal)
  - the class would be embedded in the generated code; while if a string is
provided, the size is the string itself PLUS the converted data(in run-time)

I hope we agree from this point about string literals as initializers. Let's
jump to

2) 'only' need. I proposed a related feature in a previous message, the
'modifiers' as template paramenters. I will talk also about the above
mentioned 'replacing typedef', besides I don't have it cooked enough in my
mind.
2.1) Type Modifiers: the implementer class of a generic-length integer
(let's talk later about floating point), should be able to accept sign and
size modifiers.
The proposal I did is to accept the **pure** modifier as template parameter,
additionally with a notation rule (pls refer to the message).
If 'GenericInt' is the class that implements generic length literals, I
would like it to receive the following template parameters:
template < sign_mod Sign = signed, size_mod Size = '', unsigned int Length =
0> class GenericInt;

So, I'd love to be able to say somewhere:
{
   unsigned GenericInt<100> MyInt;
   //and why not also
   MyInt = 321321321321321321321321321321321321321;
}

2.2) Replacing typedefs. This is for portability, the problem of the size.
With the size as parameter, one would like that those sizes equal to a
platform integer size should be implemented by such native type; for
example, in some platform:
     GenericInt<1>  ~ char
     GenericInt<2>  ~ short int
     GenericInt<4>  ~ int
... etc

And a header file provided by the platform for such conversions.

The 'proposal' I did not propose yet, is about this, and has the idea of
giving the 'typedef' the ability of stating type mappings. For example:

template<sign_mod Sign> typedef Sign GenericInt<1> Sign char;

which maps
   GeneralInt<Sign, '', 1>
TO
   Sign char

(replacing Sign with the appropiate value, i.e. 'signed' or 'unsigned').

I agree that the latter (2.2) is not mature enough.

finally,
3) Why the library implementation: considering the point 2, this GeneralInt
could be provided as part of the STL, and the 'mapping' header containing
the replacing typedefs a platform-specific file (abstracted to the
developer).


PLEASE, remember that *ALL* of the text above is just for justifying a
'generic length literal support' proposal.

Thanks!

Daniel.

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

danielgutson@hotmail.com (danielgutson@hotmail.com) wrote
> I'd also like your feedback about supporting generic-length literals,
> as the base for generic-length integral numbers.
[snip]
> This proposal, together with the 'type modifier template parameter',
> would be the basic features for generic-length numeric classes as
> library implementations.

It seems to me that this proposal would BE the basics of an
generic-length numeric class. You almost wouldn't need a library
implementation, if you could do this.

However, note that you can create a generic-length numeric library
class using the existing language. It would allow you to use an
integer type in a manner almost completely analagous to ints and longs,
except that literals would have to be handled differently.

> MySuperInt x(987987987987987987987987987987987987987987987987987);
would change to
  MySuperInt x("987987987987987987987987987987987987987987987987987");


> MySuperInt y = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF;
would change to
  MySuperInt y = "0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF";

Would you consider this a minor inconvenience? Would you consider it
a major inconvenience? Would it make this arbitrary-precision integer
completely useless, at least for your purpose? Please defend your answer.

Note that both C and C++ have a bias for extending the library, rather
than the core language. It's not insurmountable, but if you really
want this proposal to go through you ought to explain why you really
need this built-in instead of just in the library.

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

Newsgroup people:
 I'd also like your feedback about supporting generic-length literals,
as the base for generic-length integral numbers.

First, my proposal starts with a compiler-implemented template class.
The initial interface I thought looks like:

template <typename T> class Literal
{
public:
   enum Sign { Positive, Negative };

   T operator [] (size_t index) const;
   const T* asPtr(void) const;

   size_t length(void) const;

   Sign sign(void) const;    //not sure about this
private:
   Literal();   // performed by compiler
};

So, the idea is that the compiler can generate this class similarly
the 'typeinfo' fashion.
For example, we can receive it in the constructor of a class (or any
other function parameter):

class MySuperInt
{
public:
    MySuperInt( const Literal<int>& lit );
    ...
};

so somewhere:

{
    MySuperInt x(987987987987987987987987987987987987987987987987987);
    MySuperInt y = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF;
}

I can say the following characteristics of Literal:

1) length() returns the size in terms of the template parameter
[integral] type
2) the class is created during compile-time, and embedded in the code;
the conversion of the original must be performed (by the compiler)
from the literal to the template type, if possible (including
hexadecimal, etc.).

I didn't solve it for floats and doubles yet (comments welcommed).

This proposal, together with the 'type modifier template parameter',
would be the basic features for generic-length numeric classes as
library implementations.
(please refer to my 'inline constants && type modifiers as template
parameters' proposal).

Open issues:
  * add another enum and method to provide information about the
literal type? (i.e. decimal, hexadecimal)?
  * floating point base types (float/double)
  * replace the 'asPtr' method and [] operator by a (const T*) casting
operator?

Thanks!
   Daniel.

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