Re: change of socketport constructor

[Dimitar Dimitrov]

Hi Klaus,

I still see some problems with the patch you sent. May be I miss something
but here is what I think:

1. The attach() method of SocketPort being protected forces the derived class 
to call it in its own constructor (there are other variants but this is most 
probably the way it's going be used).
Now think about a situation when there is one level more in the class 
hierarchy. If there is a class derived form the class that is already derived 
from SocketPort we end up with the initial problem - the service thread is 
running before the object is fully constructed (the object is attached to the 
service in the class immediately derived from SocketPort!!!). I don't see a 
good way to clean this. May be separating creation of the SocketPort from 
attaching it to the service. That means making attach public and going for 
two-step process - create then attach. The problem here is that this approach 
will most probably break some existing code.
Any opinions...??

2. About expired() method. The problems I see here is that some compilers 
depending on the warning level will not complain if a method does not return 
a value when it is supposed to. That means if there is some code that doesn't 
return anything because of the old signature of expired() will still compile 
without problems if the warning level is low. I don't know who compiles with 
switched off warnings so may this is not that relevant anyway...

Regards,
Dimitar