C++ Object Scope – How to Understand Differences in Object Behavior in Local vs Global/Class Scope

c++objectscope

In the code below, the WiFiClient object changes behavior depending on whether it is assigned to a locally scoped or non-locally scoped variable.

Locally scoped:

#include <WiFi.h>

char ssid[] = "[redacted]";    // your network SSID (name)
char pass[] = "[redacted]";        // your network password
int status = WL_IDLE_STATUS;
WiFiServer server(80);

void setup()
{
    Serial.begin(115200);
    while (status != WL_CONNECTED) {
        status = WiFi.begin(ssid, pass);
        delay(5000);
    }
   
    server.begin();
}


void loop()
{
    WiFiClient client = server.available();
    if (client) {
        Serial.println("new client connected");
        String currentLine = "";
        while (client.connected()) {
            if (client.available()) {
                char c = client.read();
                Serial.write(c);
                if (c == '\n') {
                    if (currentLine.length() == 0) {
                        //do something
                    } else {
                        currentLine = "";
                    }
                } else if (c != '\r') {
                    currentLine += c;
                }
            }
        }
        client.stop();
        Serial.println("client disconnected");
    }
}

Output (when client connects):

// execution resumes here from blocking server.available() after a client connects ...

[INFO] A client connected to this server :
[PORT]: 58620
[IP]:192.168.2.36

new client connected
GET / HTTP/1.1
Host: 192.168.2.172
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,fil;q=0.8
Cookie: __guid=259319114.1308697201864418800.1719734660203.9114

Non-locally scoped:

#include <WiFi.h>

char ssid[] = "[redacted]";    // your network SSID (name)
char pass[] = "[redacted]";        // your network password
int status = WL_IDLE_STATUS;
WiFiServer server(80);
WiFiClient client;

void setup()
{
    Serial.begin(115200);
    while (status != WL_CONNECTED) {
        status = WiFi.begin(ssid, pass);
        delay(5000);
    }
   
    server.begin();
}

void loop()
{
    client = server.available();
    if (client) {
        Serial.println("new client connected");
        String currentLine = "";
        while (client.connected()) {
            if (client.available()) {
                char c = client.read();
                Serial.write(c);
                if (c == '\n') {
                    if (currentLine.length() == 0) {
                        //do something
                    } else {
                        currentLine = "";
                    }
                } else if (c != '\r') {
                    currentLine += c;
                }
            }
        }
        client.stop();
        Serial.println("client disconnected");
    }
}

Output (when client connects):

// execution resumes here from blocking server.available() after a client connects ...

[INFO] A client connected to this server :
[PORT]: 51193
[IP]:192.168.2.36

new client connected
client disconnected

[INFO] A client connected to this server :
[PORT]: 51192
[IP]:192.168.2.36

new client connected
client disconnected

[INFO] A client connected to this server :
[PORT]: 51194
[IP]:192.168.2.36

new client connected
client disconnected

// ...continues indefinitely

According to Arduino's documentation for server.available(), the behavior observed when WiFiClient is not locally scoped isn't normal, and I've already reported the problem to the developers of the SDK I'm using. However, I'd like to understand, in general, why assigning an object within different scopes in C/C++ can cause such a change in behavior.

Aside from putting WiFiClient in a globally scoped variable, as above, I also tried making it a class member. I also tried various things to try to get it to work, such as storing a pointer or reference to the WiFiClient object, none of which worked.

I've mainly used interpreter-based languages and haven't yet encountered an issue like this. My previous experience conditioned me to believe that an object should behave relatively the same in different scopes (I'll admit that it took an embarrassing amount of time to narrow the issue down to changes in variable scope because of that expectation), so this is really new and fascinating to me.

Obviously, a more specific discussion of why what I experienced above occurred would require intimate knowledge of the Arduino framework and the SDK I'm using, so that's not what I'm asking. I'd really like to know more conceptually why such an issue can occur in the first place.

Additional detail: I forgot to mention that server.available() is blocking — although there is a non-blocking mode, it isn't enabled here to further rule out the issue being caused by that mode. The issues occur on the very first trip through loop(). Execution halts at WiFiClient client = server.available()/client = server.available() until a client connects. The Serial Monitor outputs I include start immediately after a client connects. I've also edited those outputs to make that clearer.

Best Answer

There are at least 2 differences (which are related) between the versions:

In the local version the following line:
```
WiFiClient client = server.available();
```
calls the constructor of WiFiClient. But in the global version this line:
```
client = server.available();
```
calls the assignment operator (move/copy) which is potentially different.
The loop function is called in a loop by the Arduino system code.
Every time is it called a new instance of by this line:
```
WiFiClient client = server.available();
```
Then every time the loop function returns the scope of client will also end and it will be destructed.

This is different from the global version where the same instance of client is always used (but as mentioned above it is assigned every call of loop). Note that in the global case a temporary object is constructed for every assignment (and then destructed).

Both differences (construction vs assignment, and multiple destructions of client) are actually aspects of the same cause - the local/global scope.

Related Solutions

C++ – What Does {0} Mean When Initializing an Object

What's happening here is called aggregate initialization. Here is the (abbreviated) definition of an aggregate from section 8.5.1 of the ISO spec:

An aggregate is an array or a class with no user-declared constructors, no private or protected non-static data members, no base classes, and no virtual functions.

Now, using {0} to initialize an aggregate like this is basically a trick to 0 the entire thing. This is because when using aggregate initialization you don't have to specify all the members and the spec requires that all unspecified members be default initialized, which means set to 0 for simple types.

Here is the relevant quote from the spec:

If there are fewer initializers in the list than there are members in the aggregate, then each member not explicitly initialized shall be default-initialized. Example:
struct S { int a; char* b; int c; };
S ss = { 1, "asdf" };
initializes ss.a with 1, ss.b with "asdf", and ss.c with the value of an expression of the form int(), that is, 0.

You can find the complete spec on this topic here

C++ Polymorphism – Why Overridden Function Hides Other Overloads

Judging by the wording of your question (you used the word "hide"), you already know what is going on here. The phenomenon is called "name hiding". For some reason, every time someone asks a question about why name hiding happens, people who respond either say that this called "name hiding" and explain how it works (which you probably already know), or explain how to override it (which you never asked about), but nobody seems to care to address the actual "why" question.

The decision, the rationale behind the name hiding, i.e. why it actually was designed into C++, is to avoid certain counter-intuitive, unforeseen and potentially dangerous behavior that might take place if the inherited set of overloaded functions were allowed to mix with the current set of overloads in the given class. You probably know that in C++ overload resolution works by choosing the best function from the set of candidates. This is done by matching the types of arguments to the types of parameters. The matching rules could be complicated at times, and often lead to results that might be perceived as illogical by an unprepared user. Adding new functions to a set of previously existing ones might result in a rather drastic shift in overload resolution results.

For example, let's say the base class B has a member function foo that takes a parameter of type void *, and all calls to foo(NULL) are resolved to B::foo(void *). Let's say there's no name hiding and this B::foo(void *) is visible in many different classes descending from B. However, let's say in some [indirect, remote] descendant D of class B a function foo(int) is defined. Now, without name hiding D has both foo(void *) and foo(int) visible and participating in overload resolution. Which function will the calls to foo(NULL) resolve to, if made through an object of type D? They will resolve to D::foo(int), since int is a better match for integral zero (i.e. NULL) than any pointer type. So, throughout the hierarchy calls to foo(NULL) resolve to one function, while in D (and under) they suddenly resolve to another.

Another example is given in The Design and Evolution of C++, page 77:

class Base {
    int x;
public:
    virtual void copy(Base* p) { x = p-> x; }
};

class Derived : public Base{
    int xx;
public:
    virtual void copy(Derived* p) { xx = p->xx; Base::copy(p); }
};

void f(Base a, Derived b)
{
    a.copy(&b); // ok: copy Base part of b
    b.copy(&a); // error: copy(Base*) is hidden by copy(Derived*)
}

Without this rule, b's state would be partially updated, leading to slicing.

This behavior was deemed undesirable when the language was designed. As a better approach, it was decided to follow the "name hiding" specification, meaning that each class starts with a "clean sheet" with respect to each method name it declares. In order to override this behavior, an explicit action is required from the user: originally a redeclaration of inherited method(s) (currently deprecated), now an explicit use of using-declaration.

As you correctly observed in your original post (I'm referring to the "Not polymorphic" remark), this behavior might be seen as a violation of IS-A relationship between the classes. This is true, but apparently back then it was decided that in the end name hiding would prove to be a lesser evil.

Best Answer

Related Solutions

C++ – What Does {0} Mean When Initializing an Object

C++ Polymorphism – Why Overridden Function Hides Other Overloads

Related Question