[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: UDSAtomTypes bitmaps??
From:       Michael Matz <matz () ifh ! de>
Date:       2000-04-07 14:36:51
[Download RAW message or body]

Hi,

On Fri, 7 Apr 2000, David Faure wrote:
> > > Well, that would work too, but what gain is there compared to the
> > > current situation ? It's exactly the same mechanism, simply with
> > > different constants...
> > 
> > More types. Note that with the current mechanism we can only have 30
> > special types (32 bit - 2 bit for base type), and we can never extend to
> > more than 4 base types.
> 
> Well, with (1<<8), (2<<8) etc we would have even less : 24 types !

??? You mean 24 bit, so we can have 1<<24 types. (5<<8,6<<8,...1532<<8)

> Room for more base types, right. But number, string and time (which is
> a number) fit all KIO needs as far as I can see.

> > Really, if a set of numbers is meant to be used exclusively, they should
> > not be powers of two, and here we have two independent set of numbers.
> 
> Bit fields are always powers of two.

No, only bitfields of width 1, but what we really want to have is:
struct type {
  int base_type:8;
  int spec_type:24;
}

These bitfields we can simulate with OR'd values ((spec_type<<8)|base_type)

Right now we have this structure:
struct type {
  int base_string:1;
  int base_long:1;
  int base_time:1;
  int spec_size:1;
  int spec_user:1;
  ....
}

In this model a value could be a NAME, a ACCESS_TIME, a STRING and a
LONG. All at the same time. Does not make sense to me.


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]