Re: [gnutls-dev] c++ interface to gnutls.h

[Rupert Kittinger-Sereinig]

Nikos Mavrogiannopoulos schrieb:
> On Thu 01 Jun 2006 23:22, you wrote:
> > Hi Nikos,
> > I have thought a little about decomposing the session class. From the
> > code I have looked at, all the state information is supposed to be
> > stored inside the gnutls_session_t. so it would be quite easy to
> > build a derived class that just acts as a wrapper that adds some more
> > functions.
>
> Hello Rupert,
>  I was quite busy and couldn't check it until today. 
>
> I like the splitting to classes, but why not use a final class that will
> inherit from all the above small classes? It looks difficult to
> properly cast the class for each function.

my basic critique was that the session class offers a lot of 
functionality, but not all of it will make sense for all instances. If 
you inherit from all the small classes, you will get the union of all 
functionality, so the interface of the final class will not be different 
 from the initial version, however the object will be much more 
complicated (probably this would require putting the gnutls_session_t 
object in a virtual base classe, etc).

so the basic idea of my proposal was to deliver only subsets of the 
functionality. This is somewhat different from the usual way inheritance 
is used, maybe this is a new design pattern :-)

I agree that the casts look complicated. But if they are applied at 
function boundaries, they may be helpful to structure the code (e.g. 
separate connection creation from data transmission, etc.


> Also you seem to prefer functions instead of member functions.
> Why is that? I think it's cleaner to see send as
> a property of the session object rather than a generic operation.

Why do you think so? the functions called from main() were just examples 
 to illustrate the idea of creating temporary objects to get suitable 
subsets of the functionality.

However, I do like designs that replace redundant meber functions with
one member function and some free functions, if they can be impelmented 
without friendship.

Herb Sutter makes a very good point for this design concept: 
http://gotw.ca/gotw/084.htm

> I've currently added the C++ interface to the unstable branch. I'll 
> update it again when i find some time...
>
> regards,
> Nikos

Another way to think about a c++ interface: what will be the advantages 
of using it? I can think of the following:
- automatic resource management
- more consistent interface (see my last email)
- exceptions for error propagation
- hide as many enums as possible (virtual functions instead of 
switch/case, provide handler functions for alerts, etc)

the last one is probably the hardest from a design point of view, but 
also the most rewarding:-)

By the way, I switched from openssl to gnutls mainly because I think the 
gnutls API is much clearer (of course, the documentation is also 
superior...).

regards,
Rupert

--
Rupert Kittinger-Sereinig <address@hidden>
Krenngasse 32
A-8010 Graz
Austria