Re: change of socketport constructor

[triendl klaus]

On Thu, 1 May 2003 23:16:11 +0200
Dimitar Dimitrov <address@hidden> wrote:

> 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.

yes, you are right. i also thought about this point (the fact that attach() is 
protected is not my idea); one solution is to let the programmer deriving his 
own class somewhere down the hierarchy from SocketPort attach his class to the 
SocketService.

the other solution is that the server (which creates the socketport) attaches 
the socket; as the server also takes care of the service(s) (e.g. it creates 
the service or chooses which one to take if more are running) this would be a 
clean solution i think.

about breaking the code: i wonder whether someone already ran successfully the 
code because i had always the problem with the virtual function tables.
so, it didn't work reliably or me at all and i don't suppose that it does for 
others. therefore breaking the code shouldn't be an issue (my opinion)


> 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...

what happens if no value is returned?
is this possible at all? because expired() is virtual, g++-3.3 complains about 
conflicting return types if void expired() is defined in a derived class; i 
don't know about other compilers.


-- 
klaus triendl