www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - const version for foreach/opApply

reply Matthias Walter <xammy xammy.homelinux.net> writes:
Hi,

trying to traverse the entries of a std.bitmanip.BitArray I stumbled
upon the following problem:

The original code is as follows:

int opApply(scope int delegate(ref bool) dg)
{
  int result;
  for (size_t i = 0; i < len; i++)
  {
    bool b = opIndex(i);
    result = dg(b);
    this[i] = b;
    if (result)
      break;
  }
  return result;
}

In case I want to accept const(BitArray) objects, it shall look like the
following (maybe using "ref const(bool)" for the delegate parameter?):

int opApply(scope int delegate(bool) dg) const
{
  int result;
  for (size_t i = 0; i < len; i++)
  {
    bool b = opIndex(i);
    result = dg(b);
    if (result)
      break;
  }
  return result;
}

Can one glue both things together into a single routine (using inout
magic or whatever)?

Best regards,

Matthias Walter
Jun 08 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 8 June 2012 at 16:33:28 UTC, Matthias Walter wrote:

 Hi,

 trying to traverse the entries of a std.bitmanip.BitArray I 
 stumbled upon the following problem:

 In case I want to accept const(BitArray) objects, it shall look 
 like the following (maybe using "ref const(bool)" for the 
 delegate parameter?):

 int opApply(scope int delegate(bool) dg) const



 Can one glue both things together into a single routine (using 
 inout magic or whatever)?


  I want to say you can't, because ref bool. If you ignore the 
reference, you don't need the non-const version (I think).

  I am currently working on BitArray updates, and it is 
const/immutable friendly according to as many tests as I could 
come up with for valid usage; This has taught me a lot on using 
templates, traits, constraints and how inout actually works. I 
haven't tried for a bit but I can try once more to send my code 
to GitHub, then you can give it a try.
Jun 08 2012
parent reply Matthias Walter <xammy xammy.homelinux.net> writes:
On 2012-06-08 22:47, Era Scarecrow wrote:

 On Friday, 8 June 2012 at 16:33:28 UTC, Matthias Walter wrote:

 Hi,

 trying to traverse the entries of a std.bitmanip.BitArray I stumbled
 upon the following problem:

 In case I want to accept const(BitArray) objects, it shall look like
 the following (maybe using "ref const(bool)" for the delegate
 parameter?):

 int opApply(scope int delegate(bool) dg) const


 

 Can one glue both things together into a single routine (using inout
 magic or whatever)?


 
  I want to say you can't, because ref bool. If you ignore the reference,
 you don't need the non-const version (I think).
 
  I am currently working on BitArray updates, and it is const/immutable
 friendly according to as many tests as I could come up with for valid
 usage; This has taught me a lot on using templates, traits, constraints
 and how inout actually works. I haven't tried for a bit but I can try
 once more to send my code to GitHub, then you can give it a try.


First, thank you for your answer. I've already made some tiny
modifications in order to make BitArray work for my purposes:

https://github.com/xammy/phobos/commit/eb46d99217f2bf1e6d173964e2954248b08146d6

If you plan to create pull requests for your changes - please consider
my changes as well. When do you expect to finish, i.e., create a pull
request for phobos?
Jun 09 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 9 June 2012 at 10:09:25 UTC, Matthias Walter wrote:

 First, thank you for your answer. I've already made some tiny 
 modifications in order to make BitArray work for my purposes:

 https://github.com/xammy/phobos/commit/eb46d99217f2bf1e6d173964e2954248b08146d6

 If you plan to create pull requests for your changes - please 
 consider my changes as well. When do you expect to finish, 
 I.e., create a pull request for phobos?


  Curious... Almost all of the changes you proposed I've already 
added in my version, the toHash is the only one missing and I 
don't know if I can work that very well. The new version is going 
to include 'slice-like' features, which is mostly a couple extra 
numbers specifying the offset in bits from the beginning to the 
end; The problem with that is hashing would have a huge speed 
drop.

  I'm adding an 'realign' function that handles those cases, but 
the downside is shared slices where you would want to make 
changes may or may not work. Caching the result would also be 
useful... Hmmm...

  I don't suppose you have a toHash where I can enter the odd bits 
and then also bulk ones and have the hash return the same could 
you? I can see xor easily having this type of effect...

  Anyways, here's some things I can do so far; Got a few 
improvements left to do, but not many. (const & immutable 
friendly of course :) )

--

const BitArray ba = BitArray([1,1,0,0,1]);
const BitArray slice = ba[1 .. ba.length];
BitArray m = slice.dup;
immutable BitArray im = slice.idup;

assert(slice == ba[1 .. ba.length]);
assert(slice == [1,0,0,1]);
assert(slice == m);
assert(slice == im);

assert(slice.isCompact);
writeln("GC not used");
Jun 09 2012
parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 06/10/2012 12:30 AM, Era Scarecrow wrote:

 On Saturday, 9 June 2012 at 10:09:25 UTC, Matthias Walter wrote:

 First, thank you for your answer. I've already made some tiny
 modifications in order to make BitArray work for my purposes:

 https://github.com/xammy/phobos/commit/eb46d99217f2bf1e6d173964e2954248b08146d6


 If you plan to create pull requests for your changes - please consider
 my changes as well. When do you expect to finish, I.e., create a pull
 request for phobos?


 
  Curious... Almost all of the changes you proposed I've already added in
 my version, the toHash is the only one missing and I don't know if I can
 work that very well. The new version is going to include 'slice-like'
 features, which is mostly a couple extra numbers specifying the offset
 in bits from the beginning to the end; The problem with that is hashing
 would have a huge speed drop.
 
  I'm adding an 'realign' function that handles those cases, but the
 downside is shared slices where you would want to make changes may or
 may not work. Caching the result would also be useful... Hmmm...
 
  I don't suppose you have a toHash where I can enter the odd bits and
 then also bulk ones and have the hash return the same could you? I can


I see the problem. I don't know whether my hash function is a good one -
I just needed it to make AAs work with BitArray as a key type.

But the question is interesting. Finding a good hash function for bit
arrays which is invariant under realignment.


 see xor easily having this type of effect...
 
  Anyways, here's some things I can do so far; Got a few improvements
 left to do, but not many. (const & immutable friendly of course :) )
 
 -- 
 
 const BitArray ba = BitArray([1,1,0,0,1]);
 const BitArray slice = ba[1 .. ba.length];
 BitArray m = slice.dup;
 immutable BitArray im = slice.idup;
 
 assert(slice == ba[1 .. ba.length]);
 assert(slice == [1,0,0,1]);
 assert(slice == m);
 assert(slice == im);
 
 assert(slice.isCompact);
 writeln("GC not used");
 


Looks interesting!
Jun 10 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 08 Jun 2012 12:33:20 -0400, Matthias Walter  
<xammy xammy.homelinux.net> wrote:


 Hi,

 trying to traverse the entries of a std.bitmanip.BitArray I stumbled
 upon the following problem:

 The original code is as follows:

 int opApply(scope int delegate(ref bool) dg)
 {
   int result;
   for (size_t i = 0; i < len; i++)
   {
     bool b = opIndex(i);
     result = dg(b);
     this[i] = b;
     if (result)
       break;
   }
   return result;
 }

 In case I want to accept const(BitArray) objects, it shall look like the
 following (maybe using "ref const(bool)" for the delegate parameter?):

 int opApply(scope int delegate(bool) dg) const
 {
   int result;
   for (size_t i = 0; i < len; i++)
   {
     bool b = opIndex(i);
     result = dg(b);
     if (result)
       break;
   }
   return result;
 }

 Can one glue both things together into a single routine (using inout
 magic or whatever)?


Not currently, because we have an issue of inout having two different  
meanings.

When a function's parameters or return values are adorned with inout,  
inout becomes sort of a wildcard.

When inside a function, however, inout turns into a restrictive form of  
const.

But what happens with a delegate parameter that *takes* an inout  
parameter?  For example:

int opApply(scope int delegate(ref inout(bool)) dg) inout

Is inout(bool) a wildcard for the delegate?  Or is part of the inout  
wildcard of the entire function?  Inside opApply, should it be the  
restrictive const type?

Currently, it is a wildcard for the delegate, and so it doesn't really  
help, once you go into opApply, you can't temporarily remove the inout  
type.

Note that for your particular instance I'd *recommend* two different  
versions, since the const version can be vastly optimized (passing a bool  
by value vs. by reference is much more efficient, and then there is no  
need to re-store the value after the delegate).

There are quite a few ideas being floated around as to how to make inout  
work for opApply, but for now, you should avoid it.

-Steve
Jun 25 2012