X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Packets%2FPacketParser.hh;h=b5ef0ea7a0e7b6dff10a05fb82965bb5ab89027b;hb=5443435c4c2b6e4386c5334b5b8358273f2bae93;hp=9be6b2915a90c568be1906329111a81b3d4a1070;hpb=43ebe17b77586542dff65f2535815a19812e4316;p=senf.git

diff --git a/Packets/PacketParser.hh b/Packets/PacketParser.hh
index 9be6b29..b5ef0ea 100644
--- a/Packets/PacketParser.hh
+++ b/Packets/PacketParser.hh
@@ -136,22 +136,22 @@
     parsers). When defining composite parsers without the help of the \ref packetparsermacros, you
     should provide those same members.
 
-    \subsection parserimpl_packet Packet parsers
+    \subsection parserimpl_packet Protocol parsers
 
-    Packet parsers are composite parsers with relaxed requirements. Since a packet parser will never
-    be used as a sub-parser (it will not be used within another composite parser or as value type in
-    a collection parser), the value returned by senf::bytes for this parser must not necessarily
-    cover the complete packet (e.g. if the packet has a trailer, the trailer will live outside the
-    range given by senf::bytes). You may define any member you want to have in your packets field
-    interface. These members may access the packet data in any way. You just need to ensure, that
-    the integration into the packet-type is correct (the senf::PacketTypeMixin will by default use
-    senf::bytes() to find the end of the header).
+    Protocol parsers are composite parsers with relaxed requirements. Since a Protocol parser will
+    never be used as a sub-parser (it will not be used within another composite parser or as value
+    type in a collection parser), the value returned by senf::bytes for this parser must not
+    necessarily cover the complete packet (e.g. if the packet has a trailer, the trailer will live
+    outside the range given by senf::bytes). You may define any member you want to have in your
+    packets field interface. These members may access the packet data in any way. You just need to
+    ensure, that the integration into the packet-type is correct (the senf::PacketTypeMixin will by
+    default use senf::bytes() to find the end of the header).
 
     <hr>
  */
 
-#ifndef HH_PacketParser_
-#define HH_PacketParser_ 1
+#ifndef HH_SENF_Packets_PacketParser_
+#define HH_SENF_Packets_PacketParser_ 1
 
 // Custom includes
 #include <boost/utility/enable_if.hpp>
@@ -354,6 +354,16 @@ namespace senf {
                                              parsers when access to previous or following packets is
                                              needed e.g. for calculating checksums etc. */
 
+        void resize(size_type oldSize, size_type newSize); ///< Resize data container
+                                        /**< This command will erase or insert bytes from/into the
+                                             data container at the end of the parser (at i() + \a
+                                             newSize). If \a oldSize is > \a newSize, bytes will be
+                                             removed, otherwise bytes will be inserted.
+
+                                             \warning This may invalidate iterators and other
+                                                 parsers. The current parser itself is automatically
+                                                 updated */
+
     private:
         data_iterator end() const;
 
@@ -499,8 +509,8 @@ namespace senf {
 
 ///////////////////////////////hh.e////////////////////////////////////////
 #endif
-#if !defined(HH_Packets__decls_) && !defined(HH_PacketParser_i_)
-#define HH_PacketParser_i_
+#if !defined(HH_SENF_Packets_Packets__decls_) && !defined(HH_SENF_Packets_PacketParser_i_)
+#define HH_SENF_Packets_PacketParser_i_
 #include "PacketParser.cci"
 #include "PacketParser.ct"
 #include "PacketParser.cti"