X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Socket%2FFileHandle.hh;h=afb4cd2d3d411a5f34b12117a7befca162358285;hb=81ffa1c459b96dd44472bcef37e1e373934ee138;hp=2f6b09f0bd32b2d73d76df1a20515ed3a961bfe9;hpb=85ab07d100a382467a42e19d741d403a7a96c951;p=senf.git

diff --git a/Socket/FileHandle.hh b/Socket/FileHandle.hh
index 2f6b09f..afb4cd2 100644
--- a/Socket/FileHandle.hh
+++ b/Socket/FileHandle.hh
@@ -28,40 +28,30 @@
 
     \image html FhHierarchy.png
 
-    The senf::FileHandle class is the base of a hierarchy of socket
-    handle classes (realized as templates). These classes provide an
-    interface to the complete socket API. While going down the
-    inheritance hierarchy, the interface will be more and more
-    complete.
-
-    The most complete interface is provided by
-    senf::ProtocolClientSocketHandle and
-    senf::ProtocolServerSocketHandle. The template Arguments specifies
-    the Protocol class of the underlying socket type. These are the
-    \e only classes having public constructors and are therefore the
-    only classes, which may be created by the library user. You will
-    normally use these classes by naming a specific socket typedef
-    (e.g. senf::TCPv4ClientSocketHandle).
-
-    However, to aid writing flexible and generic code, the socket
-    library provides the senf::ClientSocketHandle and
-    senf::ServerSocketHandle class templates. These templates
-    implement a family of closely related classes based on the
-    specification of the socket policy. This policy specification may
-    be \e incomplete (see below). Instances of
-    senf::ClientSocketHandle/senf::ServerSocketHandle can be assigned
-    and converted to different ClientSocketHandle/ServerSocketHandle
-    types as long as the policy specifications are compatible.
-
-    \attention It is very important, to (almost) always pass the socket
-    handle <em>by value</em>. The socket handle is a very lightweight
-    class and designed to be used like an ordinary built-in type. This
-    is very important in combination with the policy interface.
-
-    \note The FileHandle hierarchy below the SocketHandle template is
-    \e not meant to be user extensible. To add new socket types, you
-    should introduce new protocol and/or policy classes, the
-    SocketHandle classes should not be changed.
+    The senf::FileHandle class is the base of a hierarchy of socket handle classes (realized as
+    templates). These classes provide an interface to the complete socket API. While going down the
+    inheritance hierarchy, the interface will be more and more complete.
+
+    The most complete interface is provided by senf::ProtocolClientSocketHandle and
+    senf::ProtocolServerSocketHandle. The template Arguments specifies the Protocol class of the
+    underlying socket type. These are the \e only classes having public constructors and are
+    therefore the only classes, which may be created by the library user. You will normally use
+    these classes by naming a specific socket typedef (e.g. senf::TCPv4ClientSocketHandle).
+
+    However, to aid writing flexible and generic code, the socket library provides the
+    senf::ClientSocketHandle and senf::ServerSocketHandle class templates. These templates implement
+    a family of closely related classes based on the specification of the socket policy. This policy
+    specification may be \e incomplete (see below). Instances of
+    senf::ClientSocketHandle/senf::ServerSocketHandle can be assigned and converted to different
+    ClientSocketHandle/ServerSocketHandle types as long as the policy specifications are compatible.
+
+    \attention It is very important, to (almost) always pass the socket handle <em>by
+    value</em>. The socket handle is a very lightweight class and designed to be used like an
+    ordinary built-in type. This is very important in combination with the policy interface.
+
+    \note The FileHandle hierarchy below the SocketHandle template is \e not meant to be user
+    extensible. To add new socket types, you should introduce new protocol and/or policy classes,
+    the SocketHandle classes should not be changed.
  */
 
 #ifndef HH_FileHandle_
@@ -87,10 +77,10 @@ namespace senf {
         not readable or writable or only using special function calls like sendto).
 
         The FileHandle class provides handle/body handling and uses automatic reference
-        counting. The senf::FileHandle istance is very lightweight and should be used like a
+        counting. The senf::FileHandle instance is very lightweight and should be used like a
         built-in type.
 
-        \attention You should mostly pass around senf::FileHandle objects by \e value und not by
+        \attention You should mostly pass around senf::FileHandle objects by \e value and not by
         reference.
 
         The FileHandle abstraction is only applicable to real filehandles. It is \e not possible to
@@ -105,12 +95,9 @@ namespace senf {
         \section filehandle_new Writing senf::FileHandle derived classes
 
         To build a new FileHandle type you need to derive from senf::FileHandle. The derived class
-        will have to call the protocted FileHandle constructor passing a new senf::FileBody
+        will have to call the protected FileHandle constructor passing a new senf::FileBody
         instance. This instance may either be a simple senf::FileBody or a class derived from
         senf::FileBody.
-
-        \todo Add public default constructor to allow declaration of (empty) senf::FileHandle
-        variables.
      */
     class FileHandle
         : public SafeBool<FileHandle>
@@ -123,7 +110,9 @@ namespace senf {
         ///\name Structors and default members
         ///@{
 
-        // protected default constructor
+        FileHandle();
+
+        // my default constructor
         // default copy constructor
         // default copy assignment
         // default destructor
@@ -137,11 +126,11 @@ namespace senf {
                                      /**< \throws senf::SystemException */
         void terminate();            ///< Close filehandle ignoring error conditions
 
-        bool readable() const;       ///< Check, wether a read on the handle would not block
+        bool readable() const;       ///< Check, whether a read on the handle would not block
                                      ///< (ignoring blocking state)
         void waitReadable() const;   ///< Wait, until read on the handle would not block (ignoring
                                      ///< blocking state)
-        bool writeable() const;      ///< Check, wether a write on the handle would not block
+        bool writeable() const;      ///< Check, whether a write on the handle would not block
                                      ///< (ignoring blocking state)
         void waitWriteable() const;  ///< Wait, until a write on the handle would not block
                                      ///< (ignoring blocking state)
@@ -163,7 +152,7 @@ namespace senf {
                                         FileHandle */
 
         bool boolean_test() const;  ///< Short for valid() && ! eof()
-                                    /**< This is called when using a FileHandle instance in a boolen
+                                    /**< This is called when using a FileHandle instance in a boolean
                                        context
 
                                        See the performance comments for the eof() member */
@@ -220,4 +209,6 @@ namespace senf {
 // c-file-style: "senf"
 // indent-tabs-mode: nil
 // ispell-local-dictionary: "american"
+// compile-command: "scons -u test"
+// comment-column: 40
 // End: