[gnutls-dev] c++ interface to gnutls.h
rks at mur.at
Wed Jun 7 00:38:53 CEST 2006
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
> 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
Herb Sutter makes a very good point for this design concept:
> I've currently added the C++ interface to the unstable branch. I'll
> update it again when i find some time...
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
Rupert Kittinger-Sereinig <rks at mur.at>
More information about the Gnutls-devel