X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Socket%2FSocketPolicy.hh;h=39d358e9b45c170ae5bbf5aa9a79243dcfa992ec;hb=55d09e34a5b9a9c7af23cc5ecb0ab79d58757a2d;hp=bc7ffc740d61846e32019a831125ae12bcf98415;hpb=5ed1fa1c42763aebad06c1e4ac8fc5a19e15519a;p=senf.git

diff --git a/Socket/SocketPolicy.hh b/Socket/SocketPolicy.hh
index bc7ffc7..39d358e 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 <g0dil@berlios.de>
 //
 // This program is free software; you can redistribute it and/or modify
@@ -23,29 +23,25 @@
 /** \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
-        <map name="socketPolicy">
-          <area shape="rect" alt="SocketPolicy" href="structsenf_1_1SocketPolicy.html" title="SocketPolicy" coords="276,90,558,213" />
-          <area shape="rect" alt="WritePolicyBase" href="structsenf_1_1WritePolicyBase.html" title="WritePolicyBase" coords="39,243,174,268" />
-          <area shape="rect" alt="ReadPolicyBase" href="structsenf_1_1ReadPolicyBase.html" title="ReadPolicyBase" coords="42,204,174,231" />
-          <area shape="rect" alt="CommunicationPolicyBase" href="structsenf_1_1CommunicationPolicyBase.html" title="CommunicationPolicyBase" coords="0,166,215,193" />
-          <area shape="rect" alt="FramingPolicyBase" href="structsenf_1_1FramingPolicyBase.html" title="FramingPolicyBase" coords="30,129,185,155" />
-          <area shape="rect" alt="AddressingPolicyBase" href="structsenf_1_1AddressingPolicyBase.html" title="AddressingPolicyBase" coords="17,90,200,116" />
-        </map>
-        <img src="SocketPolicy.png" border="0" alt="Socket Policy" usemap="#socketPolicy">
-    \endhtmlonly
+    <div class="diamap" name="SocketPolicy">
+    <span coords="39,229,182,257">\ref WritePolicyBase</span>
+    <span coords="17,76,210,105">\ref AddressingPolicyBase</span>
+    <span coords="29,114,194,143">\ref FramingPolicyBase</span>
+    <span coords="368,0,463,28">\ref PolicyBase</span>
+    <span coords="275,2,691,185">\ref SocketPolicy</span>
+    <span coords="0,152,227,181">\ref CommunicationPolicyBase</span>
+    <span coords="41,191,180,219">\ref ReadPolicyBase</span>
+    </div>
+    \htmlonly <img src="SocketPolicy.png" border="0" alt="SocketPolicy" usemap="#SocketPolicy"> \endhtmlonly
         
     \section policy_group_introduction Introduction to the Policy Framework
 
@@ -65,7 +61,7 @@
 
     <dt><em>readPolicy</em></dt><dd>configures the readability of the socket</dd>
 
-    <dt><em>writePolicy</em></dt><dd>configures the writability of the socket</dd>
+    <dt><em>writePolicy</em></dt><dd>configures the writability of the socket</dd></dl>
 
     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
@@ -210,10 +206,10 @@
     \code
       struct ExampleAddressingPolicy
       {
-          template <class Policy>
-          void connect(senf::SocketHandle<Policy> handle, Address & addr,
+          template <class SPolicy>
+          void connect(senf::SocketHandle<SPolicy> handle, Address & addr,
                        typename senf::IfCommmunicationPolicyIs<
-                           Policy, senf::ConnectedCommunicationPolicy>::type * = 0);
+                           SPolicy, senf::ConnectedCommunicationPolicy>::type * = 0);
       };
     \endcode
 
@@ -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
@@ -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