C++ std::vector in a array of classes

General JUCE discussion
1

I have changed some architecture of my app to make it more sensical and not use as many pointers. I am having a little problem from time to time. If I declare an array of a class with a vector inside. Sometimes the second classes vector doesn’t get instantiated. How do I ensure that it does. See trivial code below?

class Something
{
    
public:
    Something() {};
    ~Something() {};
    std::vector<float> values;
}

class Owner {
public:
    Owner() {
        for(int i=0;i<2;i++)
        {
            for(int s=0;s<10;s++)
            {
                somethings[i].values.push_back((float)s);
            }
        }
    }
    ~Owner() {};
    Something somethings[2];
}

int main()
{
    Owner owns;
    float x1 = owns.somethings[0].values[3];
    float x2 = owns.somethings[1].values[6]; // sometimes throws error
}
2

I think your example is a bit confusing:
You don’t have an array of Owners. An Owner has an array of Somethings.

So the correct call should be:
owns.somethings[3].values[6]

3

Yes you are correct sorry bad demo code. (edited)
I was just trying to illustrate the structure I am having a problem with.
In this case the first array class vector (of Something) gets constructed but the second one doesn’t occasionally. I am trying to figure out why

4

Your code looks correct now. Which compiler/configuration did you use which it failed on?

5

Since the crashing is “random”, I suspect there are multiple threads involved, is that true? (std::vector etc are not thread safe.)

6

There are values in that are instantiated in the UI thread and called from in the audio thread but it only crashes on start up. Once it’s running I have a memory block.
see Locks, RAII best practice

The problem is here. When I instantiate the processor class I’m expecting the vectors to be instantiated aswell but say 1 in 7 times the audio engine calls back for some data and it isn’t.

processor = std::make_shared<ProcessorTypeI>(); // this has classes with vector
audioEngine = std::make_shared<AudioEngine>(processor); // this calls them in the loop

The relevant structure of the processor class is detailed above.

7

Maybe I am misreading this, but is your expectation that the processor exists and can function completely if the user closes the gui?

8

No that’s not the intended use case.
The audioEngine class is just an extended AudioIODeviceCallback class.
Both are shared pointers as quite a few components can access certain methods. I get this error though if they are just standard pointers.

9

Honestly though this probably only happens with debug build as another operation changes the vector before anything else. It just feels like there’s a bug from me not knowing some quirk about c++

10

In general I would not use a shared pointer unless you really need to. In your use case I would have expected processor and audioEngine to be unique pointers. Using shared pointers instead of raw pointers when you are not interested in ownership will lead to issues in complex applications. Then again I may be assuming to much based on the example you gave.

11

Actually the reason I used shared pointer for the processor is that the processor may be accessed even when the audioEngine goes out of scope. You are probably right about the audioEngine, My use case is not a typical one though. No real problem for my application.

My problem is with vector initialisation as member of class which is in an array of said class.