On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
> You can go for simpler separation:
>
> struct BitArray{
> //() - is an empty template spec
> 	ref BitArrayopSliceAssign()(const BitArray ba, int start, int end)
> {
> //two bit array can try balk mode etc.

 I'll give it a try, it may very well be what I need; although I wouldn't have thought you could declare it like that. I have much to learn in the ways of the template.

>>  course if the 'in' keyword is the key i will have to test that to make sure.
> in == scope const not sure what scope buys here but couldn't hurt.

 If it can avoid making a new copy, then it likely would help. I'll need to test it. I actually am not quite sure how scope works as an argument; it isn't really covered in TDPL from what I recall.

On Monday, 30 July 2012 at 22:23:46 UTC, Era Scarecrow wrote:
> On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
>> in == scope const not sure what scope buys here but couldn't hurt.
>
> If it can avoid making a new copy, then it likely would help. I'll need to test it. I actually am not quite sure how scope works as an argument; it isn't really covered in TDPL from what I recall.

 Tests with 'in' doesn't help, only ref and catching a temporary seem to prevent postblits.



Also the empty template doesn't work, somehow I'm not surprised...

template X(bool something) {
 struct XT {
   void func()(XT x){
        writeln("XT template called: typeID:", typeid(x));
   }
 }
}

alias X!true.XT A;
alias X!false.XT B;

A a, b;
B ba;

a.func(b); //passes
a.func(ba);

Error: template test.X!(true).XT.func does not match any function template declaration
Error: template test.X!(true).XT.func() cannot deduce template function from argument types !()(XT)

On 31-Jul-12 02:40, Era Scarecrow wrote:
> On Monday, 30 July 2012 at 22:23:46 UTC, Era Scarecrow wrote:
>> On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
>>> in == scope const not sure what scope buys here but couldn't hurt.
>>
>> If it can avoid making a new copy, then it likely would help. I'll
>> need to test it. I actually am not quite sure how scope works as an
>> argument; it isn't really covered in TDPL from what I recall.
>
>   Tests with 'in' doesn't help, only ref and catching a temporary seem
> to prevent postblits.
>
>
>
> Also the empty template doesn't work, somehow I'm not surprised...
>
> template X(bool something) {
>   struct XT {

Fixed :

>     void func(bool smth)(X!(smth).XT x){

By default XT is deduced as X!(current value of smth).XT

>          writeln("XT template called: typeID:", typeid(x));
>     }
>   }
> }
>
> alias X!true.XT A;
> alias X!false.XT B;
>
> A a, b;
> B ba;
>
> a.func(b); //passes
> a.func(ba);
>
> Error: template test.X!(true).XT.func does not match any function
> template declaration
> Error: template test.X!(true).XT.func() cannot deduce template function
> from argument types !()(XT)


-- 
Dmitry Olshansky

On Monday, 30 July 2012 at 22:44:21 UTC, Dmitry Olshansky wrote:
> Fixed :
>
>>    void func(bool smth)(X!(smth).XT x){
>
> By default XT is deduced as X!(current value of smth).XT

Doesn't really fix it...

    a.func(b); //65 - doesn't match declaration.
    a.func(ba); //66
    //other template tests not worth putting, 67-70
    a.func!true(b); //71 - explicitly stated
    a.func!false(ba); //72
    a.func!false(b); //73 - Backwards on purpose for test
    a.func!true(ba); //74

(65): Error: template test.X!(true).XT.func does not match any function template declaration
(11): Error: template test.X!(true).XT.func(bool smth) cannot deduce template function from argument types !()(XT)

(66): Error: template test.X!(true).XT.func does not match any function template declaration
(11): Error: template test.X!(true).XT.func(bool smth) cannot deduce template function from argument types !()(XT)

(73): Error: function test.X!(true).XT.func!(false).func (XT x) is not callable using argument types (XT)
(73): Error: cannot implicitly convert expression (b) of type XT to XT
(74): Error: function test.X!(true).XT.func!(true).func (XT x) is not callable using argument types (XT)
(74): Error: cannot implicitly convert expression (ba) of type XT to XT

On Mon, Jul 30, 2012 at 11:19 PM, Era Scarecrow <rtcvb32@yahoo.com> wrote:

>> void func(T)(X!T x)
>> {}
>>
>> void main()
>> {
>>     X!bool b;
>>     X!int i;
>>     func(b);
>>     func(i);
>> }
>
>
>  Hmmm i do think that seems right... but if it contains multiple parameters,
> then...?
>
> template X(x1, x2, x3) {
>  struct XT {}
> }
>
>> void func(T)(X!T x) {}
>
> Will this still work?

No. Use a 3-params template or a tuple:

void func(A,B,C)(X!(A,B,C) x) {}

or

void func(Ts...)(X!(Ts) x) {}

or even, more general:

void func(T)(T x) if (is(T t = X!(SomeTypes), SomeTypes...)), because
template constrains are much more powerful and general than fiddling
arguments types.

There was a discussion between Simen Kjaeraas and me on the subject not long ago. Kenji Hara extended the functionnality of is( , T...) and did a pull request. I'm not sure it's in 2.060, the request was done a week ago.


>> void tempFunc(T,U)(T t, U u) if (is(T a == X!(SomeType), SomeType) &&
>> is(U a == X!(SomeType), SomeType)
>>                                                 || is(T == XY) && is(U ==
>> XY))
>> {
>> ...
>> }
>> Is that what you need?
>
>
>  I want to say no... But I haven't actually tested it for my use cases.
> Leaving it unconstrained (without checking) to make it work is a disaster
> waiting to happen: I want T and U to both be of the same template (X in this
> case) but not the same instantiation arguments.

Said like this, it's much more clear for me :)

Note that in the above code, SomeType is a fresh variable in each is()
expression. So, even though I used the same name (shouldn't have done
that), T and U can have different type parameters.

*shameless plug*
Btw, I wrote a tutorial on templates, you can find it here:

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf

(click on 'view raw', that should download the pdf)

That should shed some light on the matters at hand.

On Tuesday, 31 July 2012 at 05:27:58 UTC, Philippe Sigaud wrote:
> No. Use a 3-params template or a tuple:
>
> void func(A,B,C)(X!(A,B,C) x) {}
> or
> void func(Ts...)(X!(Ts) x) {}

 I don't know how many arguments it will have (depends on how many options I give it), and I honestly don't; It should be invisible for the end user as long as we can get the the constraints properly accepted.

> or even, more general:
>
> void func(T)(T x) if (is(T t = X!(SomeTypes), SomeTypes...)), because template constrains are much more powerful and general than fiddling arguments types.

 That doesn't make sense; but I don't have a full grasp of the templates (continued below).

> There was a discussion between Simen Kjaeraas and me on the subject not long ago. Kenji Hara extended the functionnality of is( , T...) and did a pull request. I'm not sure it's in 2.060, the request was done a week ago.

 so the (, T...) is shorthand for testing the template type with multiple arguments. Nice. So multiple arguments would be...

 struct X (T, U) {}

 if(is(T t = X!(bool, bool), (int, int), (int, bool)))  //?

>> I want to say no... But I haven't actually tested it for my use cases. Leaving it unconstrained (without checking) to make it work is a disaster waiting to happen: I want T and U to both be of the same template (X in this case) but not the same instantiation arguments.
>
> Said like this, it's much more clear for me :)
>
> Note that in the above code, SomeType is a fresh variable in each is() expression. So, even though I used the same name (shouldn't have done that), T and U can have different type parameters.

> *shameless plug*
> Btw, I wrote a tutorial on templates, you can find it here:
>
> https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf
>
> (click on 'view raw', that should download the pdf)
> That should shed some light on the matters at hand.

 Indeed... I remember glancing through it, but never really needed it badly; Now it seems I do. At least it's not C++ and it's templates. I'll be reading up on them starting tonight (and printing most of it); It is after all the hardest part (and most powerful part) of the language :P

On 29/07/12 23:36, bearophile wrote:
> Era Scarecrow:

>>> Another commonly needed operation is a very fast bit count. There are very refined algorithms to do this.
>
>>  Likely similar to the hamming weight table mentioned in TDPL.
>> Combined with the canUseBulk I think I could make it fairly fast.
>
> There is lot of literature about implementing this operation
> efficiently. For the first implementation a moderately fast (and short)
> code is probably enough. Later faster versions of this operation will go
> in Phobos, coming from papers.

See bug 4717. On x86, even on 32 bits you can get close to 1 cycle per byte, on 64 bits you can do much better.

 Currently since I've been concentrating more on bitfields and BitArray needs more work, the two separate patches and trees are out of sync and apparently the auto-tester brings them up as a fail. How do I remove one of the pulls so I can concentrate on the one set of features and continue the others later?

 (Course I could just update what I have for BitArray so it works as a value-type for now too...)

On Thursday, 2 August 2012 at 11:11:58 UTC, Era Scarecrow wrote:
> How do I remove one of the pulls so I can concentrate on the one set of features and continue the others later?

Hm? You can just close pull requests (button at the bottom of the page), and reopen them later.

David

On Thursday, 2 August 2012 at 11:26:42 UTC, David Nadlinger wrote:
> On Thursday, 2 August 2012 at 11:11:58 UTC, Era Scarecrow wrote:
>> How do I remove one of the pulls so I can concentrate on the one set of features and continue the others later?
>
> Hm? You can just close pull requests (button at the bottom of the Page), and reopen them later.

 Most of this doesn't make sense to me still; just one of those things I'll learn as I use it over the next few years. Anyways when the bitfields are as updated as we're going to make it, I'll resume work on BitArray code.

 In the meantime I guess I'll check on the auto-tester once it refreshes.