At 01:38 PM 3/2/2001 -0800, Hong Zhang wrote:
> > 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?
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> One needs to specify *which* PDP is the target. The PDP-11 was the
DS> most popular of the bunch, and it's a 16-bit machine. One of the
DS> TOPS machines was 36 bit, IIRC, with either 7 or 9 bit
DS> chars. (Can't remember which)
> 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
At 02:02 PM 3/2/2001 -0600, Jarkko Hietaniemi wrote:
>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 l
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
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 th
I believe we should use low bits for tagging. It will make switch
case much faster.
If you still emphasize on speed, we can make
0x05 => UTF-8
0x06 => UTF-16
0x07 => UTF-32
#define IS_UTF_ANY(a) \
(((a)->flags & 0x07) >= UTF-8)
However, I don't believe it is needed.
Hong
> If your inter
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 wil
> >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 bits, depending
> both on the size of an I
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_"
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 NATIV
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 battl
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
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 wh
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 actual flags:
>7|6|5|4|3|2|1|0
>0 0 0 0 1 x x x = UTF && U
> =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 =
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 Cs. There is an
> > C typedef that is guaranteed to hold any integer type.
>
>[gazing into crystal ball . . . ] I pred
On Fri, 2 Mar 2001, Dan Sugalski wrote:
> At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote:
> > > Integer data types are generically referred to as Cs. There is an
> > > C typedef that is guaranteed to hold any integer type.
> >
> The intention is that if you need to deal with integers in an abstrac
On Fri, 2 Mar 2001, Dan Sugalski wrote:
> =head2 Intger data types
>
> Integer data types are generically referred to as Cs. There is an
> C typedef that is guaranteed to hold any integer type.
[gazing into crystal ball . . . ] I predict some header somewhere is going
to already #define "INT".
At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote:
> > Integer data types are generically referred to as Cs. There is an
> > C typedef that is guaranteed to hold any integer type.
>
>Does such thing exist? Unless it is BIGINT.
I'm confused here, looks like you're missing some words from those sentence
> Integer data types are generically referred to as Cs. There is an
> C 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, but
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
22 matches
Mail list logo
