Qt causes conflicting function names

I've run into a problem where I have to create a socket on my own (not using the Qt sockets due to a bug) and have found that sockets on both *nix and windows have a connect() function that conflicts with Qt's connect() functions for signals and slots.

I only need to use this connect function in one file. Is there a way to keep my program from picking up the Qt connect function instead of the socket connect function?

Thanks,
Paul

Use ::connect() to use the connect from BSD sockets. By the way, what bug are you talking about?

I'm writing a small app that uses the libssh2 library to make a simple ssh client. The library needs to have a socket created and then takes the socket descriptor and uses that.

I was making a trial app to test the libraries functionallity to make sure that it would do what I needed it to do and was also seeing how I could integrate it with Qt. So I figured that I would use Qt's sockets to make my life easier. I found that on windows, my little test app creates the Qt socket just fine and the library can use it without problem (although the Qt socket doesn't seem to fire off signals when data is ready to be read...). But when running under linux, the library doesn't work. It bombs out when trying to exchange the encryption keys.

Now there is a simple example that comes with the library that shows how to use to make a ssh connection. That example works just fine on both windows and linux. So at this point I'm trying to figure out exactly where the problem resides. I'm leaning towards this being a Qt socket bug problem since the lib example works on both OS when using their native socket creation methods. One other thing to test is to take their example and make the socket with a Qt socket and see if it still doesn't work.

Paul

That's not really a bug. Qt sockets are not meant to be used this way, thus you should use BSD sockets directly. There is no benefit in using QTcpSocket there, so there is no point in using it.

Quote:

---

Originally Posted by wysota

...There is no benefit in using QTcpSocket there, so there is no point in using it.

---

I think I'm going to disagree with you there. I think that this is actually a prime example of one use of Qt sockets. I'd like to take advantage of Qt signals for when data arrives on the socket and is ready to be read instead of creating code to handle polling the socket every so often (windows) or using some other method (linux - select). With Qt, I can go without needing to create any methods to check for data, I can just link a simple signal/slot.

According to the 4.3 doc on QAbstractSocket, they do mention that one of the uses if you need a socket is "Create a native socket descriptor, instantiate QAbstractSocket, and call setSocketDescriptor() to wrap the native socket."

Might as well take advantage of Qt if I can to make my life easier! Course, with that little description, I realize that I'm going about it wrong. I should be natively creating the socket and then create a QAbstractSocket and give it the native socket descriptor. I'm currently doing it backwards. Hopefully some more experimentation tonight or tomorrow night will shed more light.

Paul

Quote:

---

Originally Posted by thomaspu

I think I'm going to disagree with you there. I think that this is actually a prime example of one use of Qt sockets. I'd like to take advantage of Qt signals for when data arrives on the socket and is ready to be read instead of creating code to handle polling the socket every so often (windows) or using some other method (linux - select). With Qt, I can go without needing to create any methods to check for data, I can just link a simple signal/slot.

---

But the library you are using is in control of the socket, not Qt, so you won't receive any signals. You can try using QSocketNotifier, but you don't need to use QTcpSocket with it - you can go directly for BSD sockets.

Quote:

---

According to the 4.3 doc on QAbstractSocket, they do mention that one of the uses if you need a socket is "Create a native socket descriptor, instantiate QAbstractSocket, and call setSocketDescriptor() to wrap the native socket."

---

Yes, but that's when you want to use the socket with Qt interface and this is not the case here - you're using the ssh library instead. These two components simply won't interact, they rely on completely different mechanisms. Try using the socket notifier if all you want is to be informed that data is available in the socket (though you can achieve that with a plain ::select() call).

Hmm... well that makes sense why the Qt socket was never sending a notification signal when data was available on the socket. I was looking over the doc for the QSocketNotifier and that looks like it will do the trick. Now I just need to find out if that will effect the functionality on Windows: "The socket passed to QSocketNotifier will become non-blocking, even if it was created as a blocking socket".

I hope that doesn't pose a problem. I'll have to look at the library to see if they set the socket to be a blocking socket. And if thats the case, well, just more code to write.

Thanks for the response wysota, I think you might have just saved me a bunch of time scratching my head wondering why part of it doesn't work.

Paul