Particle.variable declaration in object constructor stopped working

I declared a variable using Particle.variable() in the constructor for a c++ object, using a private int variable in the class. It worked great for two years, but when I went to recomple and flash it the other day it compiled fine, but the photon would stop with a flashing red SOS. I tracked it down to the Particle.variable call in the object constructor by commenting that statement out, and seeing it ran fine (but without actually creating the variable of course.)

Has there been a change in the runtime to disallow declaring object private members as Particle.variables?

Here’s a simple example:

obclass.h:

// Test object class
//
#ifndef OBCLASS_H
#define OBCLASS_H

#include "application.h"
class obclass {
    private:
        int state;      // 1 = on, 0 = off
    public:
        obclass( char *vname_state);
};
#endif

obclass.cpp:

#include "obclass.h"

obclass::obclass( char *vname_state ){
        // Commenting this out makes the program not fail!
        Particle.variable(vname_state, state);
}

vartest.ino:

#include "obclass.h"

static obclass ob = obclass( "obname");
void
setup ()
{
        Particle.publish ("startup", "Started obclass test  program v2.4");
}

void
loop()
{
        Particle.publish("status", "loop interation");
        delay (5000);
}

Yes, there was a change.
At the time of instatiation of your object the Particle object is not fully instantiated which then leads to an SOS panic.
The way to get around this - and how it should have been done always - is to add a class::begin() or class::init() function which is executed by your code and not implicitly during object construction.

BTW, I don’t think that exposing a private field of a class this way isn’t really best style.

1 Like

Thanks for the explanation.

I’ll try your suggestion, but it makes for somewhat less clean structure,. I wanted to hide as much detail in my objects as possible including declaration of particle.variables, and doing this in the constructor seemed a simple way to accomplish this.

But I now see an alternative implementation not involving the extra setup() function that should be almost as clean.