X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Socket%2FSocketPolicy.hh;h=af32b65c15009f9a2e6738d410b505a9398f41a2;hb=532240d72e09e19e57fac9bb55c2560b9c9e5b97;hp=bc7ffc740d61846e32019a831125ae12bcf98415;hpb=5ed1fa1c42763aebad06c1e4ac8fc5a19e15519a;p=senf.git diff --git a/Socket/SocketPolicy.hh b/Socket/SocketPolicy.hh index bc7ffc7..af32b65 100644 --- a/Socket/SocketPolicy.hh +++ b/Socket/SocketPolicy.hh @@ -1,8 +1,8 @@ // $Id:SocketPolicy.hh 218 2007-03-20 14:39:32Z tho $ // // Copyright (C) 2006 -// Fraunhofer Institute for Open Communication Systems (FOKUS) -// Competence Center NETwork research (NET), St. Augustin, GERMANY +// Fraunhofer Institute for Open Communication Systems (FOKUS) +// Competence Center NETwork research (NET), St. Augustin, GERMANY // Stefan Bund // // This program is free software; you can redistribute it and/or modify @@ -23,30 +23,26 @@ /** \file \brief Policy Framework public header - \todo Do we want to support separate read and write policies. This allows to treat pipes within - this framework however, is this worth the effort? - - \idea Creating a new Socket will create 4 (!) new instances (The handle, the body, the policy - and the protocol) of which 3 (argh) (body, policy and protocol) live on the heap. This is - expensive. We should convert all the policy classes to singletons and assign the same - instance to all socket bodies with the same policy. This would reduce the number of heap - allocations per socket handle to two. + \idea Creating a new Socket will create 3 new instances (The handle, the body, the policy) of + which 2 (argh) (body, policy) live on the heap. This is expensive. We should convert all the + policy classes to singletons and assign the same instance to all socket bodies with the same + policy. This would reduce the number of heap allocations per socket handle to one (which is + already optimized using the pool_alloc_mixin) */ /** \defgroup policy_group The Policy Framework - \htmlonly - - SocketPolicy - WritePolicyBase - ReadPolicyBase - CommunicationPolicyBase - FramingPolicyBase - AddressingPolicyBase - - Socket Policy - \endhtmlonly - +
+ \ref WritePolicyBase + \ref AddressingPolicyBase + \ref FramingPolicyBase + \ref PolicyBase + \ref SocketPolicy + \ref CommunicationPolicyBase + \ref ReadPolicyBase +
+ \htmlonly SocketPolicy \endhtmlonly + \section policy_group_introduction Introduction to the Policy Framework The policy framework conceptually implements a list of parallel inheritance hierarchies each @@ -65,7 +61,7 @@
readPolicy
configures the readability of the socket
-
writePolicy
configures the writability of the socket
+
writePolicy
configures the writability of the socket
The template senf::SocketPolicy combines these policy axis to form a concrete socket policy. In a concrete policy, each of these policy axis is assigned a value, the policy value. This value @@ -74,7 +70,7 @@ from the axis base class FramingPolicyBase. This base class also doubles as UnspecifiedFramingPolicy (which is just a typedef alias). If a policy axis is assigned this Unspecified type, the axis is left unspecified, the concrete policy will be incomplete. - + The senf::SocketPolicy template defines the behavior of a socket handle. The socket handle instances do not implement any socket functionality themselves instead deferring the implementation to the policy classes. The SocketHandle interface is therefore \e not implemented @@ -133,7 +129,7 @@ meta-programming are needed. However, this information is only needed if you want to write new policy classes or want to use the policy framework explicitly for your own involved optimizations ... or if you are just plain curious :-) - + In the following discussion we will use the following conventions: \li \e Axis is one or \c AddressingPolicy, \c FramingPolicy, \c CommunicationPolicy, \c ReadPolicy or \c WritePolicy @@ -210,10 +206,10 @@ \code struct ExampleAddressingPolicy { - template - void connect(senf::SocketHandle handle, Address & addr, + template + void connect(senf::SocketHandle handle, Address & addr, typename senf::IfCommmunicationPolicyIs< - Policy, senf::ConnectedCommunicationPolicy>::type * = 0); + SPolicy, senf::ConnectedCommunicationPolicy>::type * = 0); }; \endcode @@ -241,8 +237,8 @@ as base classes to build other policy classes. */ -#ifndef HH_SocketPolicy_ -#define HH_SocketPolicy_ 1 +#ifndef HH_SENF_Socket_SocketPolicy_ +#define HH_SENF_Socket_SocketPolicy_ 1 // Custom includes @@ -296,7 +292,7 @@ namespace senf { */ struct AddressingPolicyBase { - virtual ~AddressingPolicyBase() {} + virtual ~AddressingPolicyBase(); class Address { Address(); }; }; @@ -313,7 +309,7 @@ namespace senf { */ struct FramingPolicyBase { - virtual ~FramingPolicyBase() {} + virtual ~FramingPolicyBase(); }; /** \brief Policy defining, how peers are selected @@ -328,7 +324,7 @@ namespace senf { The \c listen member is straight forward. The \c accept() member must return a new file descriptor (which will be used to create a new SocketHandle of the correct - type). + type). \note This Policy only has two meaningful states: ConnectedCommunicationPolicy and UnconnectedCommunicationPolicy. It is probably not sensible to define a new @@ -338,7 +334,7 @@ namespace senf { */ struct CommunicationPolicyBase { - virtual ~CommunicationPolicyBase() {} + virtual ~CommunicationPolicyBase(); }; /** \brief Policy defining the readability @@ -361,7 +357,7 @@ namespace senf { */ struct ReadPolicyBase { - virtual ~ReadPolicyBase() {} + virtual ~ReadPolicyBase(); }; /** \brief Policy defining the writability @@ -384,7 +380,7 @@ namespace senf { */ struct WritePolicyBase { - virtual ~WritePolicyBase() {} + virtual ~WritePolicyBase(); }; // The implementation file will for each Policy declared above @@ -463,6 +459,8 @@ namespace senf { information. */ AddressingPolicyBase const & theAddressingPolicy() const = 0; + + virtual ~SocketPolicyBase(); }; /** \brief Collection of policy classes