Arcane Jill wrote:
> In article <cbbr47$2tbk$1@digitaldaemon.com>, Stewart Gordon says...
> 
>> And would I be right to assume you're still trying to make up your mind which bit slicing approach to go for?  Maybe we should have a vote....
> 
> My vote would go to (1) ABI consistency with other types. That necessarily implies copy-by-reference, and (therefore) bit-slicing only on byte boundaries.
<snip>
> (2) Copy-by-value slicing - this would allow you to maintain the ABI for slices (but not for bit-pointers).
> 
> (3) Complete linguistic consistency with other types - this would require special structures for bit-slices and bit-pointers, thereby violating ABI consistency.
> 
> Either (2) or (3) would allow slicing on non-byte boundaries, and only (3) would allow you to take the address of an element of a bit-array.

Yes, there's a trade-off between ABI consistency, semantic consistency and versatility.

(1) achieves ABI consistency, and some degree of semantic consistency only as far as the cases that work work consistently with other types.

(2) can be implemented as strict CBV, or as a superset of (1).  Either way, semantic consistency is lost, but in the second case only in what (1) can't do at all....

I suppose (3) would get my vote.  Full semantic consistency, full versatility.  Bit arrays are an inherently special type anyway, so I suppose we can get away with defining a special ABI for them.  Moreover, bit pointers would be consistent with other pointers - just as an int* can point to an arbitrary int, a bit* could point to an arbitrary bit.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

In article <cbc0ii$4gr$1@digitaldaemon.com>, Hauke Duden says...
>
>This can be dangerous, since you often check TYPE.max if you want to know the upper limit of the possible values (perhaps because you want to create a lookup structure or something of the kind). If max defines only the legal range then any other value is likely to result in "bad" behaviour like program crashes. It could also be a potential security risk, as it creates an opportunity for buffer overflow attacks.
>
>Hauke

That is a good point. You may well be right,

That said, I think that your argument only holds true for char. I don't see it holding true for dchar - that is, I don't see anyone crafting a lookup table even with 0x110000 entries in it, because that would be a HUGE lookup table. (And I *DEFINITELY* don't think that anyone would increase the size of their lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you and I both know because of our Unicode property lookup techniques, if the table is sparse (which, for dchars, it will be) there are better representations than a single humungous lookup table.

So how about a new, revised, suggestion:
char.max = 0xFF
wchar.max = 0xFFFF
dchar.max = 0x0010FFFF

(and this would mean that char.init <= char.max, which actually makes more sense than my original suggestion).

If you're still not happy, I'll drop the suggestion altogether.

Arcane Jill

How about proposing the addition of a new, character specific property (sorry I have no suggestions for a name) and leave max to it's (IMHO) intuitive meaning.

On Wed, 23 Jun 2004 15:04:13 +0000 (UTC)
Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <cbc0ii$4gr$1@digitaldaemon.com>, Hauke Duden says...
> >
> >This can be dangerous, since you often check TYPE.max if you want to know the upper limit of the possible values (perhaps because you want to create a lookup structure or something of the kind). If max defines only the legal range then any other value is likely to result in "bad" behaviour like program crashes. It could also be a potential security risk, as it creates an opportunity for buffer overflow attacks.
> >
> >Hauke
> 
> That is a good point. You may well be right,
> 
> That said, I think that your argument only holds true for char. I don't see it holding true for dchar - that is, I don't see anyone crafting a lookup table even with 0x110000 entries in it, because that would be a HUGE lookup table. (And I *DEFINITELY* don't think that anyone would increase the size of their lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you and I both know because of our Unicode property lookup techniques, if the table is sparse (which, for dchars, it will be) there are better representations than a single humungous lookup table.
> 
> So how about a new, revised, suggestion:
> char.max = 0xFF
> wchar.max = 0xFFFF
> dchar.max = 0x0010FFFF
> 
> (and this would mean that char.init <= char.max, which actually makes more sense than my original suggestion).
> 
> If you're still not happy, I'll drop the suggestion altogether.
> 
> Arcane Jill
> 
> 
> 
> 

Arcane Jill wrote:
> In article <cbc0ii$4gr$1@digitaldaemon.com>, Hauke Duden says...
> 
>>This can be dangerous, since you often check TYPE.max if you want to know the upper limit of the possible values (perhaps because you want to create a lookup structure or something of the kind). If max defines only the legal range then any other value is likely to result in "bad" behaviour like program crashes. It could also be a potential security risk, as it creates an opportunity for buffer overflow attacks.
>>
>>Hauke
> 
> 
> That is a good point. You may well be right,
> 
> That said, I think that your argument only holds true for char. I don't see it
> holding true for dchar - that is, I don't see anyone crafting a lookup table
> even with 0x110000 entries in it, because that would be a HUGE lookup table.
> (And I *DEFINITELY* don't think that anyone would increase the size of their
> lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you
> and I both know because of our Unicode property lookup techniques, if the table
> is sparse (which, for dchars, it will be) there are better representations than
> a single humungous lookup table.

I didn't mean a simple linear table - there are other possible data structures that can rely on the upper limit for the values.

For example, if you use the technique we use for the Unicode tables in a more generalized way you could end up with something like this:

class Foo(VALTYPE,INDEXTYPE)
{	
const int PAGESIZEBITS = 16;

//the following is the crucial line
const int PAGECOUNT = (INDEXTYPE.max+1) / (1<<PAGESIZEBITS);
	
VALTYPE** pages;

this()
{
pages = new VALTYPE*[PAGECOUNT];		
}

VALTYPE lookup(INDEXTYPE index)
{
//this will cause a crash if index > INDEXTYPE.max
return pages[index>>PAGESIZEBITS][index & (1<<PAGESIZEBITS)-1];
}
}

Of course this is only a simplified example, but it shows how container templates may use the max property to allocate the necessary space. It doesn't have to be a simple linear array.

> So how about a new, revised, suggestion:
> char.max = 0xFF
> wchar.max = 0xFFFF
> dchar.max = 0x0010FFFF
> 
> (and this would mean that char.init <= char.max, which actually makes more sense
> than my original suggestion).

This doesn't really solve the problem. My main concern is that the type can hold values that are bigger than the "max" value.

> If you're still not happy, I'll drop the suggestion altogether.

Peter Wood suggested in another post to instead create a new property with a different name. What do you think about that? Something like "maxValid" perhaps?

Hauke

"Derek" <derek@psyc.ward> wrote in message news:1rjnyzcq4q0ih.11hscruppphwb.dlg@40tude.net...
> I assume that these optional arguments are passed as 'in' rather than
'out'
> or 'inout'?

_arguments[] is passed as 'in'. _argptr is actually a local variable.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cbbr47$2tbk$1@digitaldaemon.com...
> > Doing that is next on my list, as well as addressing the large backlog
of
> > phobos work and compiler bugs.
> <snip>
> Addressing bugs tends to come first on my lists....

What matters most are issues (bugs or feature lack) that impact the most projects. Lack of typesafe varargs prevented a redesign of printf that is just a long standing open sore with D, affecting nearly every program written in D.

> And would I be right to assume you're still trying to make up your mind which bit slicing approach to go for?  Maybe we should have a vote....

It's nice to have the bit slicing, but it isn't an issue for many projects.

Walter wrote:
<snip>
> What matters most are issues (bugs or feature lack) that impact the most
> projects.

I don't see how there manages to be quite so little overlap between the PendingPeeves, the bugs I've encountered and the bugs that the average project wants fixed.  OK, so there's quite a bit of overlap between the first two....

One of mine could certainly do with

http://www.digitalmars.com/drn-bin/wwwnews?D/25715 et seq....

> Lack of typesafe varargs prevented a redesign of printf that is
> just a long standing open sore with D, affecting nearly every program
> written in D.

Good to see one of them at least being thought about.  I shall wait to see what you come up with....

<snip>
> It's nice to have the bit slicing, but it isn't an issue for many projects.

Well, if there's anything precluding the ready-made fixes being put in, it ought to be made not yet implemented, rather than leaving in a completely non-functional implementation.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cbccrk$oa8$1@digitaldaemon.com...
> Walter wrote:
> <snip>
> > What matters most are issues (bugs or feature lack) that impact the most
> > projects.
>
> I don't see how there manages to be quite so little overlap between the PendingPeeves, the bugs I've encountered and the bugs that the average project wants fixed.  OK, so there's quite a bit of overlap between the first two....

The thing is, everyone has a different list <g>.

Walter wrote:

> The big change here is the revamping of the typeinfo system, and the
> addition of typesafe variadic functions. At last, we can now write a proper
> successor to printf!

Here's a half-baked attempt that uses far too many templates for its own good:

http://andy.tadan.us/d/format.zip

 -- andy

fwiw, my (wasted) vote is that the bit type dies

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbbtqr$59$1@digitaldaemon.com...
> In article <cbbr47$2tbk$1@digitaldaemon.com>, Stewart Gordon says...
> >
> >And would I be right to assume you're still trying to make up your mind which bit slicing approach to go for?  Maybe we should have a vote....
>
> My vote would go to (1) ABI consistency with other types. That necessarily implies copy-by-reference, and (therefore) bit-slicing only on byte boundaries. Exceptions should be thrown for bit-slicing on non-byte boundaries; Taking the address of an element of a bit-array should be a compile-time error.
>
> But there are other alternatives, any of which I could be happy with. These include (but are probably not limited to):
>
> (2) Copy-by-value slicing - this would allow you to maintain the ABI for slices
> (but not for bit-pointers).
>
> (3) Complete linguistic consistency with other types - this would require special structures for bit-slices and bit-pointers, thereby violating ABI consistency.
>
> Either (2) or (3) would allow slicing on non-byte boundaries, and only (3)
would
> allow you to take the address of an element of a bit-array.
>
> Arcane Jill
>
>
>