On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> Janice Caron wrote:
>
>  > You might want to consider moving up. :-)
>
> Hm. And so we come full circle. I started out with D2, but the performance
>  impact of using invariant strings (for may application) is just to costly.

In that case, you might want to consider moving up, and using mutable strings.

Hint: char[] works on D2 equally as well as on D1. :-)

Here's another possibility you might try:

    struct BitFields
    {
        ubyte n;

        uint a() { return (n >> 6) & 3; }
        uint b() { return (n >> 4) & 3; }
        uint c() { return (n >> 2) & 3; }
        uint d() { return (n) & 3; }

        void a(uint x) { n &= 0x3F; n |= (x & 3) << 6; }
        void b(uint x) { n &= 0xCF; n |= (x & 3) << 4; }
        void c(uint x) { n &= 0xF3; n |= (x & 3) << 2; }
        void d(uint x) { n &= 0xFC; n |= (x & 3); }
    }

Viola. Bitfields in D1.

Janice Caron wrote:

> On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> > Janice Caron wrote:
> > 
> >  > You might want to consider moving up. :-)
> > 
> > Hm. And so we come full circle. I started out with D2, but the performance
> >  impact of using invariant strings (for may application) is just to costly.
> 
> In that case, you might want to consider moving up, and using mutable strings.
> 
> Hint: char[] works on D2 equally as well as on D1. :-)

Yes. But the string library does not.

Is your memory really this bad?

b.

-- 

On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> Yes. But the string library does not.

Yet. It's in-progress.

>  Is your memory really this bad?

Please don't get personal. You get personal; I add you to my email filter and I don't see your posts any more. It's that simple.

Your choices would seem to be:
(1) wait until Phobos adds in-place string functions
(2) write your own in-place string functions
(3) write your own bitfields class

Since I already did (3) for you a few posts up, you have a head start
on one of the options.

== Quote from Janice Caron (caron800@googlemail.com)'s article
> On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> > Really? Which documentation are you reading because the documentation on my
> >  harddrive that D1/Phobos
> Oops. Using D2.
> D2 has bitfields. You might want to consider moving up. :-)

Bit fields and bit arrays are intended to solve different problems.
But fortunately, D2 just moves BitArray from std.bitarray to std.bitmanip
so no problem.


Sean

Janice Caron Wrote:

> On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> > Yes. But the string library does not.
> 
> Yet. It's in-progress.
> 
> >  Is your memory really this bad?
> 
> Please don't get personal. You get personal; I add you to my email filter and I don't see your posts any more. It's that simple.
> 
> Your choices would seem to be:
> (1) wait until Phobos adds in-place string functions
> (2) write your own in-place string functions
> (3) write your own bitfields class
> 
> Since I already did (3) for you a few posts up, you have a head start
> on one of the options.

It is good news that std.string is changing. I read it now and it seems many functions want string but they could work with const(char) and char[]. These functions should take the superclass of all three const(char)[].

How does D2 solve the problem of passing the same qualifier to the return as it is in the parameter? In the Javari language there is a keyword romaybe. Thank you, Dee Girl

Janice Caron wrote:

> Please don't get personal. You get personal; I add you to my email filter and I don't see your posts any more. It's that simple.

You're right. I apologise. That is a far better solution.

b.
-- 

== Quote from Dee Girl (deegirl@noreply.com)'s article
> Janice Caron Wrote:
> > On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
> > > Yes. But the string library does not.
> >
> > Yet. It's in-progress.
> >
> > >  Is your memory really this bad?
> >
> > Please don't get personal. You get personal; I add you to my email filter and I don't see your posts any more. It's that simple.
> >
> > Your choices would seem to be:
> > (1) wait until Phobos adds in-place string functions
> > (2) write your own in-place string functions
> > (3) write your own bitfields class
> >
> > Since I already did (3) for you a few posts up, you have a head start
> > on one of the options.
> It is good news that std.string is changing. I read it now and it seems many functions want string but
they could work with const(char) and char[]. These functions should take the superclass of all three
const(char)[].

There have been objections to this in the past.  I'll let someone else outline them.

> How does D2 solve the problem of passing the same qualifier to the return as it is in the parameter?
In the Javari language there is a keyword romaybe. Thank you, Dee Girl

There is a "scoped const" proposal aimed at solving this problem, but so far as I know it isn't going to be added to the language.


Sean

On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>  How does D2 solve the problem of passing the same qualifier to the return as it is in the parameter?

That is an entirely separate subject. There is a proposal on the table suggested by Steven Schveighoffer and myself which addresses that very problem, and our proposal sounds similar to your romaybe. However, that is not relevant for std.string.

== Quote from Janice Caron (caron800@googlemail.com)'s article
> On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> >  How does D2 solve the problem of passing the same qualifier to the return as it is in the parameter?
> That is an entirely separate subject. There is a proposal on the table suggested by Steven Schveighoffer and myself which addresses that very problem, and our proposal sounds similar to your romaybe. However, that is not relevant for std.string.

It's relevant in that the implementation of std.string could benefit from the proposal, were it implemented.


Sean