Yes, I know I promised the GC PDD, but this was simpler and half finished.
Now it's all finished, and can be used some in both the vtable PDD and the
utility functions PDD.
-Cut here with a sharp knife
=head1 TITLE
Perl's internal data types
=head1 VERSION
1
=head2 CURRENT
Integer data types are generically referred to as CINTs. There is an
CINT typedef that is guaranteed to hold any integer type.
Does such thing exist? Unless it is BIGINT.
Should we scrap the buffer pointer and just tack the buffer on the end
of the structure? Saves a level of indirection,
On Fri, 2 Mar 2001, Dan Sugalski wrote:
=head2 Intger data types
Integer data types are generically referred to as CINTs. There is an
CINT typedef that is guaranteed to hold any integer type.
[gazing into crystal ball . . . ] I predict some header somewhere is going
to already #define
At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
On Fri, 2 Mar 2001, Dan Sugalski wrote:
=head2 Intger data types
Integer data types are generically referred to as CINTs. There is an
CINT typedef that is guaranteed to hold any integer type.
[gazing into crystal ball . . . ] I predict
=item BINARY (0)
=item ASCII (1)
=item EBCDIC (2)
=item UTF_8 (3)
=item UTF_32 (4)
=item NATIVE_1 (5) through NATIVE_3 (7)
A little more complex, but why not use bits 3-7 as actual flags:
7|6|5|4|3|2|1|0
0 0 0 0 1 x x x = UTF UTF_8
0 0 0 1 1 x x x = UTF UTF_32
x x 1 0 1 x x x = UTF
On Fri, Mar 02, 2001 at 02:01:35PM -0500, Dan Sugalski wrote:
At 02:01 PM 3/2/2001 -0500, wiz wrote:
=item BINARY (0)
=item ASCII (1)
=item EBCDIC (2)
=item UTF_8 (3)
=item UTF_32 (4)
=item NATIVE_1 (5) through NATIVE_3 (7)
A little more complex, but why not use bits 3-7 as
On Fri, Mar 02, 2001 at 01:40:40PM -0500, Dan Sugalski wrote:
At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
Do you also want an unsigned variant? (trying to spare Nick some of
the sign preservation madness he's currently battling in perl5.)
Well, we've got an unsigned version of the
At 07:12 PM 3/2/2001 +, Nicholas Clark wrote:
On Fri, Mar 02, 2001 at 02:01:35PM -0500, Dan Sugalski wrote:
At 02:01 PM 3/2/2001 -0500, wiz wrote:
=item BINARY (0)
=item ASCII (1)
=item EBCDIC (2)
=item UTF_8 (3)
=item UTF_32 (4)
=item NATIVE_1 (5) through NATIVE_3
At 07:17 PM 3/2/2001 +, Nicholas Clark wrote:
On Fri, Mar 02, 2001 at 01:40:40PM -0500, Dan Sugalski wrote:
At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
Do you also want an unsigned variant? (trying to spare Nick some of
the sign preservation madness he's currently battling in
If your interest is in speed alone, then adding UTF_16 might offer options as
well:
FORMAT (enc_flags):
7|6|5|4|3|2|1|0
x x 0 0 1 x x x = UTF_8
x x 0 1 0 x x x = UTF_16
x x 1 0 0 x x x = UTF_32
then:
#define UTF 56
utf_encoding = UTF enc_flags;
if( utf_encoding ) {
cout "String is UTF_"
On Fri, Mar 02, 2001 at 12:05:59PM -0800, Hong Zhang wrote:
at some
points it becomes necessary to have an unsigned type for "the largest
integer" which in this case would be 72 bits.
[and on a machine with nothing larger than 32 will be 32]
Sure. The size of an INT will probably be
At 12:21 PM 3/2/2001 -0800, Hong Zhang wrote:
I believe we should use low bits for tagging. It will make switch
case much faster.
That's pretty much what I intended. The only reason not to have them as the
low bits is if there's some other field that uses multiple bits, and
optimizing for
At 12:05 PM 3/2/2001 -0800, Hong Zhang wrote:
at some
points it becomes necessary to have an unsigned type for "the largest
integer" which in this case would be 72 bits.
[and on a machine with nothing larger than 32 will be 32]
Sure. The size of an INT will probably be either 32 or 64
I was hoping to get us something that was guaranteed to hold an integer,
no
matter what it was, so you could do something like:
struct thingie {
UV type;
INT my_int;
}
What is the purpose of doing this? The SV is guaranteed to hold anything.
Why we need a type that can
14 matches
Mail list logo
