> You're welcome. Note that your need of having a structure which is
> both associative and ordered is, if not unheard-of, at least somewhat
> uncommon.

I'm parsing program blocks from a proprietary HW/SW system.  They provide the data in the form of:

Somegroupname/Someblockname
   someparam=value
   anotherparam=value
   ...
   otherparam=value
end

Somegroupname/Somediffblockname
   someparam=value
   anotherparam=value
   ...
   otherparam=value
end

Someothergroupname/Someotherblockname
   p1=value
   p2=value
   ...
   px=value
end

The data is in an ascii text file.
I need to be able to search it by group/block/parameter.
I need to be able to maintain group/block order.
There are ~hundred diff block types where the params and order of params are known...though I would rather not create all of these structures or lists ahead of time.

My greatest need at this point is to compare two files block by block.  The blocks may be in diff orders between the files but the params of each block type would always be the same in the same order.

So compare groups, blocks within groups, and the values of each param for matching group/block names.

On Fri, Aug 31, 2012 at 5:56 PM, Paul <phshaffer@gmail.com> wrote:

> The data is in an ascii text file.
> I need to be able to search it by group/block/parameter.
> I need to be able to maintain group/block order.
> There are ~hundred diff block types where the params and order of params are
> known...though I would rather not create all of these structures or lists
> ahead of time.
>
> My greatest need at this point is to compare two files block by block.  The blocks may be in diff orders between the files but the params of each block type would always be the same in the same order.
>
> So compare groups, blocks within groups, and the values of each param for matching group/block names.

I see. In that case, your original idea of having a three-tier associative array (AA in AA in AA) is better than my tuple-key suggestion, since you want to look into all three levels. Does the provider ensure that no two groups have the same name and no two blocks in a group have the same name?

If the blocks are in a different order, you don't care about order, right? Then use an AA. As params of each block always have the same order, you can use a dynamic array.

So:

struct Param
{
    string name, value;
}

struct Block
{
    string name;
    Param[] params;
}

struct Group
{
    string name;
    Block[string] blocks;
}

alias Group[string] InputFile;

InputFile file1, file2;


Maybe someone here will have a better idea?

On 08/31/2012 08:56 AM, Paul wrote:
>> You're welcome. Note that your need of having a structure which is
>> both associative and ordered is, if not unheard-of, at least somewhat
>> uncommon.
>
> I'm parsing program blocks from a proprietary HW/SW system. They provide
> the data in the form of:
>
> Somegroupname/Someblockname
> someparam=value
> anotherparam=value
> ...
> otherparam=value
> end
>
> Somegroupname/Somediffblockname
> someparam=value
> anotherparam=value
> ...
> otherparam=value
> end
>
> Someothergroupname/Someotherblockname
> p1=value
> p2=value
> ...
> px=value
> end
>
> The data is in an ascii text file.
> I need to be able to search it by group/block/parameter.
> I need to be able to maintain group/block order.
> There are ~hundred diff block types where the params and order of params
> are known...though I would rather not create all of these structures or
> lists ahead of time.
>
> My greatest need at this point is to compare two files block by block.
> The blocks may be in diff orders between the files but the params of
> each block type would always be the same in the same order.
>
> So compare groups, blocks within groups, and the values of each param
> for matching group/block names.

Wrap your string[string][string][string] in a user-defined type that provides "the 'in' operator" as well as opIndex and friends. I have started writing this but could not finish it yet:

import std.exception;

class MyTable
{
    string[string][string][string] elements;

    struct Index
    {
        string i0;
        string i1;
        string i2;
    }

    // Enables the 'auto element = myIndex in myTable' syntax
    // (Note: I should have called it Key, not Index.)
    string * opBinary(string op)(Index index)
        if (op == "in")
    {
        string * result = null;

        if (auto table0 = index.i0 in elements) {
            if (auto table1 = index.i1 in *table0) {
                if (auto element = index.i2 in *table1) {
                    result = element;
                }
            }
        }

        return result;
    }

    // Enables 'auto value = myTable[myIndex]'
    ref string opIndex(Index index)
    {
        string * result = this.opBinary!"in"(index);
        enforce(result);

        return *result;
    }

    // Enables 'myTable[myIndex] = value'
    void opIndexAssign(string value, Index index)
    {
        auto existing = this.opIndex(index);

        if (existing) {
            existing = value;

        } else {
            // TODO: ensure that this Index exists
        }
    }

    // TODO: Look up oopIndexUnary and opIndexOpAssign

    string get(Index index, string defaultValue)
    {
        string * result = this.opBinary!"in"(index);
        return result ? *result : defaultValue;
    }
}

void main()
{}

Ali

On 08/31/2012 11:55 AM, Ali Çehreli wrote:

> class MyTable

[...]

> // Enables the 'auto element = myIndex in myTable' syntax

That's wrong. For that syntax to work, the operator below should have been opBinaryRight.

> string * opBinary(string op)(Index index)

Yeah, that should have been opBinaryRight.

(And the badly designed Thunderbird removes the indentation in quoted text. Smart application or stupid designer?)

> // Enables 'auto value = myTable[myIndex]'
> ref string opIndex(Index index)
> {
> string * result = this.opBinary!"in"(index);

If I had defined opBinaryRight as I should have, then I could simply use the 'in' operator on the right-hand side:

        string * result = index in this;

> Ali

Ali
"too"

On Saturday, 1 September 2012 at 05:23:35 UTC, Ali Çehreli wrote:
> On 08/31/2012 11:55 AM, Ali Çehreli wrote:
>
> > class MyTable
>
> [...]
>
> > // Enables the 'auto element = myIndex in myTable' syntax
>
> That's wrong. For that syntax to work, the operator below should have been opBinaryRight.
>
> > string * opBinary(string op)(Index index)
>
> Yeah, that should have been opBinaryRight.
>
> (And the badly designed Thunderbird removes the indentation in quoted text. Smart application or stupid designer?)
>
> > // Enables 'auto value = myTable[myIndex]'
> > ref string opIndex(Index index)
> > {
> > string * result = this.opBinary!"in"(index);
>
> If I had defined opBinaryRight as I should have, then I could simply use the 'in' operator on the right-hand side:
>
>         string * result = index in this;
>
> > Ali
>
> Ali
> "too"

Ali I am grateful for your help but its over my head...at least at present.  Thanks.