My Issue with TcpListener listen() method

[KRS]

Hello! I'll be happy if someone will share their thought with me about this
Basically when

listen(unsigned short port);

is called like this

class C
{
        TcpListener l;
public:
        C() { l.listen(53000); };
};

C c;

int main()
{
        return 0;
}      

it prints in console
Failed to create socket

but if it's called like this

class C
{
        TcpListener l;
public:
        C() { l.listen(53000); };
};

int main()
{
        C c;
        return 0;
}

it's all good. Only difference I'm spotting is that in second variant, call is inside the main(). I want to know why is that happening, maybe I'm missing something. And is it connected with location like I noticed?

[Kvaz1r]

I think the reason in Zero initialization. Here is blog post with more human explanation - Initialization in C++ is bonkers.

[eXpl0it3r]

You'd have to trace the code to see what state isn't necessarily lining up.

But using global variables is highly discouraged and not really supported by SFML.

[Nexus]

A bit late, but the reason is not zero initialization -- both times, the same constructor is called, default-constructing the sf::TcpListener member variable.

As expl0it3r mentioned, initialization at startup (i.e. from global variables) is a big mess in C++, as there's no deterministic order. So better avoid global variables in general, good design almost always makes them obsolete.

[KRS]

I educated myself, thank you guys

[kojack]

A little more detail.
On windows, some initialisation code needs to be called to start Winsock.
In SFML, this is done in the SocketInitializer struct. It's created as a variable in SocketImpl.cpp as the file scope variable globalInitializer, it's constructor does the Winsock startup.

The problem is C++ has no defined order that static/file-scope variables are created. https://en.cppreference.com/w/cpp/language/siof  (Static Initialisation Order Fiasco)
So there's two file scope variables being made: globalInitializer (that sets up Winsock) and c (your class that needs Winsock), but there's no way to know which will be constructed first. If c is created before globalInitializer, it will fail.

In your second style, c is constructed in main. The main function is started after all static/file-scope variables have been built, so globalInitializer has definitely gotten to do its work first.

(To be accurate, the order is defined when they are all in the same cpp file. But when they are in different cpp files as is the case here, order is indeterminate)

[KRS]

Ohhhh, I see now! Thank you so much , I hate when i dont know what is happening and I must just leave it. But now I know. Тow my question is settled)