"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca1mdn$2on9$1@digitaldaemon.com...
>
> Well it seems that one insane idea of mine (bit-pointers) cannot work. Such a
> beast would conflict with the D ABI (nice new document there!) which clearly
and
> permanently lays down the law on the format for dynamic arrays.
>
> So you can't have bit-pointers. That means that nothing involving taking the address of a bit can ever work. Nor can passing a bit to a function as an inout parameter. Nor can bitslicing on non-byte boundaries.
>
> I didn't seriously expect anyone to implement bit-pointers, but the fact is, without them, the bit type is disfunctional. It can never behave as other
types.
> So maybe, as others have suggested, it might be time to let it go. The bit type was a brilliant concept, and if it could have been made to work that would
truly
> have been a feature and an eighth. But now we've been there, tried it, done that, and bought the T-shirt. Maybe now we should try for something different.
>
> No-one disputes that we need a packed bit array - it's just the bit /itself/ which is causing the problem. To be honest, I think that all we really need is something which does this:
>
> class BitArray
> >       {
> >           this(uint n);                   // assign the first 32 bits
> >           this(ulong n);                  // assign the first 64 bits
> >           this(void* p, uint byteLen);    // assign any number of bits
> >
> >           uint toUint();
> >           ulong toUlong();
> >           void write(void* p, uint byteLen);
> >
> >           bool opIndex(uint i);           // whatever bool is aliased to
> >           int opIndex(uint i, bool value);
> >           int opIndexAssign(uint i, bool value);
> >
> >           int opEquals(Object o);
> >
> >           BitArray opSlice(uint i, uint j);
> >           BitArray opSliceAssign(uint i, uint j, BitArray a);
> >           BitArray opCat(BitArray b);
> >           BitArray opCatAssign(BitArray b);
> >           BitArray opAnd(BitArray b);
> >           BitArray opAndAssign(BitArray b);
> >           BitArray opOr(BitArray b);
> >           BitArray opOrAssign(BitArray b);
> >           BitArray opXor(BitArray b);
> >           BitArray opXorAssign(BitArray b);
> >           BitArray opCom();
> >           BitArray opShl(uint n);
> >           BitArray opShlAssign(uint n);
> >           BitArray opShr(uint n);
> >           BitArray opShrAssign(uint n);
> >
> >           uint length();
> >           uint length(uint newLength);
> >           BitArray dup();
> >       }
>
> (which, incidently, is more functionality that bit[] arrays have at the
moment).
> That's pretty basic, but it'd be pretty easy to write. I could probably do that in a day.
>
> Do we need the bit - at all? I mean, given that pointer semantics are never going to work like they do for other types even IF the bugs are fixed. Plus
it'd
> be good for Walter (sort of) - no bits; no complaints. Templates will work equally well for all types. Problem solved.
>
> Someone had to try to introduce the bit, and Walter had the guts to do it. I'm proud of him for that. But when things don't work out, sometimes you just have to call it a day.
>
> I don't want to start yet ANOTHER round of what a bit/bool should or shouldn't be. Just a simple thought this time ... is it time to ditch the bit now? Is it time for a feature unrequest?
>
> I'd like to know the mood of the D users here generally.

scalar: bool is a typedef, or alias, for int
bit: does not exist
vector: BitArray class, maybe as you describe above.

Arcane Jill wrote:
> [.. smart things ..]

Yes.

 -- andy

Antti Sykäri wrote:

>Arcane Jill:
>  
>
>Premature optimization is... you know damn right.
>  
>
I don't think this saying is always true.  Sure its true for small parts of code which can easily be changed but its not true for the big picture type code.  To have something run efficiency it must be designed right from the start.  Since high level design just about always will save the most efficiency.  

Take a look at something like quake,  if the design wasn't thought though from the start it would be dead slow.  For instance without for-thought for a good hidden surface removal algorithm (which removes 99% of polygons), which is difficult to add after the engine is built, quake would have ran hundreds of times slower.

So I say get the design right in the beginning but worry about the minor optimisations later.  In this bit example, it may mean that bit cannot do everything you want because doing so would prevent optimisation in the future.

-- 
-Anderson: http://badmama.com.au/~anderson/

Arcane Jill wrote:

> class BitArray

You'll want a struct here, I guess? Besides that, I like what you say.

In article <ca3jcp$2onj$2@digitaldaemon.com>, Norbert Nemec says...
>
>You'll want a struct here, I guess?

You're right. Well spotted.