Inability to dup/~ for const arrays of class objects

Steven Schveighoffer schveiguy at yahoo.com
Tue May 28 20:59:39 PDT 2013


On Tue, 28 May 2013 23:43:49 -0400, Peter Williams  
<pwil3058 at bigpond.net.au> wrote:

> No.  I need to be able to make changes to the objects (that doesn't  
> effect their order).  It's kind of like an associative array (which I  
> did consider as a mechanism for doing what I wanted) but without  
> splitting the object into a key/value pair.
>
> One place I'm using it is for managing symbols (look ahead sets, etc) in  
> a parser generator.  The symbols' permanent home is in an associative  
> array indexed by their name (which is also included in the symbol  
> object) but they may belong to many look ahead sets.  Usually,  
> processing that requires access to attributes of the symbol (other than  
> the key) occurs when processing one of the look ahead sets and going  
> looking for the symbol table looking for the data is an unnecessary  
> complication (not to mention an efficiency hit).  Having exactly one  
> object per symbol but still being able to have it multiple sets is a big  
> efficiency gain especially when it comes to making changes to the  
> ancillary data as you only have to change it in one place.

OK, this gives more info.

You can't use const elements.  And for good reason -- the elements are not  
const, and cannot be considered const by the set.

Use mutable data, and make the *key* part of the data const.  If you wish,  
you can place inout on the indexing function, which should guarantee that  
during that function the data is not molested.  Then you basically have to  
hand-verify the insertion function does not change the data.

That's the best D can do, and it's pretty good considering what other  
alternatives there are.

-Steve


More information about the Digitalmars-d mailing list