What's the best way to loop over a vector that is a member of a vector of parent dummy objects also being looped over

[Crag_Hack]

I want to loop over a vector of objects each containing another vector of objects to be looped over in turn. The subvector object members (subjobs) need to be able to be modified from the operation methods in the worker object and not copy constructed or implicitly shared. They are accessed from different worker methods and their state needs to persist in those different worker methods. See the code below for my current setup. The parent jobs are dummy objects that contain properties for the subjobs. I copy construct the subjobs from the parent dummy job. What's the best way to do this while following proper coding techniques? Thanks!

class Worker : public QObject
{
    public:
    void start();
    void startOperation1();
    void startOperation2();

    private:
    QVector<Job> jobs;
}

class Job
{
    public:
    QVector<Job> getSubJobs() { return subJobs; }

    private:
    QVector<BackupJob> subJobs;
}

void Worker::start()
{
    startOperation1();
    startOperation2();
}

void Worker::startOperation1()
{
    for (Job& job : jobs)
        for (Job& subJob : job.getSubJobs())
            //do operation1 on each subjob here
}

void Worker::startOperation2()
{
    for (Job& job : jobs)
        for (Job& subJob : job.getSubJobs())
            //do operation2 on each subjob here
}

[ChrisW67]

@Crag_Hack said in What's the best way to loop over a vector that is a member of a vector of parent dummy objects also being looped over:

They are accessed from different worker methods and their state needs to persist in those different worker methods.

Are you saying that e.g., Job x Subjob y, has to have some state inside startOperation1() that:

• Is different from the state it has in startOperation2()..startOperationN()
• Persists between calls startOperation1()

The subvector object members (subjobs) need to be able to be modified from the operation methods in the worker object and not copy constructed or implicitly shared.

Each startOperationN() currently gets a copy of Job x subjobs independent of any other.
You want to both modify the original subjob without copying it. This is what pointers (or references) are for. However, this automatically breaks the independence between startOperationN() methods you appear to ask for. For example, what is to happen when startOperation1() modifies Job x Subjob y in a way that invalidates anything that startOperation2() thinks it knows about that subjob?

[Crag_Hack]

@ChrisW67 said in What's the best way to loop over a vector that is a member of a vector of parent dummy objects also being looped over:

Are you saying that e.g., Job x Subjob y, has to have some state inside startOperation1() that:

Is different from the state it has in startOperation2()..startOperationN()
Persists between calls startOperation1()

I am saying that the state before and after each operation is different but that those changes need to be recorded in the job object. So operation1 will change the state of the subjob and operation2 will be able to see those changes and change the state if it needs to and so on for as many operations as necessary. I should have said state changes to persist through the different worker methods.

@ChrisW67 said in What's the best way to loop over a vector that is a member of a vector of parent dummy objects also being looped over:

Each startOperationN() currently gets a copy of Job x subjobs independent of any other.
You want to both modify the original subjob without copying it. This is what pointers (or references) are for. However, this automatically breaks the independence between startOperationN() methods you appear to ask for. For example, what is to happen when startOperation1() modifies Job x Subjob y in a way that invalidates anything that startOperation2() thinks it knows about that subjob?

I was thinking I could return by reference for the getSubJobs() function but don't think that is "proper" coding practice. I think I didn't explain myself well enough... see the first part of this post.

Thanks again!

[Crag_Hack]

Things I've thought of so far but I don't think are proper... return by reference for getSubJobs(), making subJobs public, friending Worker and Job, making a Map with job name keys and subJob values in Worker, making operation methods static and calling from Job methods (too much recoding).