A strange statement in SSLEchoServer tutorial

[oop]

Ho to all,
I seen the statement qDeleteAll(m_clients.begin(), m_clients.end()); at line 81 of SSLEchoServer.cpp file of SSEchoServer tutorial project
(Qt\Examples\Qt-5.5\websockets\sslechoserver\sslechoserver.cpp).

My dubt: why call an esplicitally delete all m_clients elements using qDeleteAll() if his destructor (m_clients's destructor) call itself?
Commenting this line I did not seen memory leaks closing application with alive connections.

Sorry for my English .
Regards
Giorgio

[anda_skoa]

My dubt: why call an esplicitally delete all m_clients elements using qDeleteAll() if his destructor (m_clients's destructor) call itself?

The destructor of QList on a pointer type does not call delete on the pointers, so qDeleteAll() is needed if you want these objects to be deleted as well.

Commenting this line I did not seen memory leaks closing application with alive connections.

If by "closing application" you mean that it exited, then the operating system will have reclaimed all resources associated with the process.

Cheers,
_

[oop]

Hi,
yes you are right m_clients contains pointers to QWebSocket and they are handled and then destroyed by QWebSocketServer (I am supposing) not by m_clients (QList ) destructor.
But thus the line I mentioned above ( qDeleteAll(m_clients.begin(),m_clients.end()) is not helpful. I can comment that line, close the application naturally (calling quit()) without memory leaks with or not the qDeleteAll(m_clients.begin(),m_clients.end());.

Yes I think in this case, this line, is not helpful.
I ask for better understand.


Giorgio

[anda_skoa]

yes you are right m_clients contains pointers to QWebSocket and they are handled and then destroyed by QWebSocketServer (I am supposing)

First rule of programming: don't make assumptions.
Especially not ones that can be disproven by reading the documentation:

QWebSocketServer does not take ownership of the returned QWebSocket object. It is up to the caller to delete the object explicitly

But thus the line I mentioned above ( qDeleteAll(m_clients.begin(),m_clients.end()) is not helpful. I can comment that line, close the application naturally (calling quit()) without memory leaks with or not the qDeleteAll(m_clients.begin(),m_clients.end());.

And how did you check that? Valgrind? Some other memory profiler?

Cheers,
_

[oop]

Hi, yes assumptions are dangerous.
No I did read documentation, I simply seen that commenting that line no wrong behaviours happen in application execution also quitting it with alive connections.
No, I did check in depth because my focus is at the moment at other thinks, I seen only no memory leaks reported from Visual Studio.

At the moment I am testing and working without the above qDeleteAll() and it are working fine, though I keep in mind that line and keep ready to restore it if some problem or suspect happens.


Sorry for my English.

Cheers,
Giorgio

[anda_skoa]

No I did read documentation, I simply seen that commenting that line no wrong behaviours happen in application execution also quitting it with alive connections.

How do you know that the connections weren't closed to the application shutdown?

No, I did check in depth because my focus is at the moment at other thinks, I seen only no memory leaks reported from Visual Studio.

If you haven't investigated if that leads to leaks, how did you arrive at that conclusion?

At the moment I am testing and working without the above qDeleteAll() and it are working fine, though I keep in mind that line and keep ready to restore it if some problem or suspect happens.

Why not just keep it as intended?

Cheers,
_