Am 28.09.2013 17:21, schrieb Michael Gius:
> Hi Tommi,
>
> Adding a parameter to the function would raise the question whether to
> return a value indicating the success or failure of the connection or to
> raise an exception. Would the address than be kept on success and
> discarded on failure ? The function may become unnecessarily complicated.
Failure is always reported by exceptions in cxxtools. And it is a
exception, when the connection could not be established. So the decision
is easy.
The implementation is also easy. I have to pass the boolean parameter to
the impl. In the impl class it is just 2 more lines:
if (!realConnect)
_socket.connect(_addr, _port);
Or actually another line to set the timeout before calling connect.
_socket.connect already throws a exception if it do connect.
I would expect when connect raised an exception, that the client is in
no good state. So it would be ok, to just accept the ip address and
port. The user have to call connect again to get the client into good
state. Or he may start the server and start using the client.
Currently we have
Client::connect(const std::string& addr, unsigned short port).
This would change into
Client::connect(const std::string& addr, unsigned short port, bool
realConnect = false).
Although the signature of the method changes, it will be API compatible.
So no change in user code is needed.
>
> On the other hand, having an optional parameter like 'testConnection =
> 0' would draw the attention of the developer to the problem of the
> misnomer of the function in the http context.
>
> It would be difficult to achieve this by creating a second function with
> the same body but named something like setConnectionAddress or
> setConnectionParams, as the other function would still need to be around
> in order to not break the API.
>
> My vote goes to keep it as it is.
> May be one could add a convenience function to test the connection ( may
> be named: canConnect() - I also thought of testConnection, but then we
> would have to check the doc for the meaning of the boolean return value)
>
> Having a separate connection timeout would be a great feature.
I just implemented that. You can find the code in git.
Tommi
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general