changed include protection from #if !defined to ifndef, and added #pragma once, if possible

31 files changed, 394 insertions, 282 deletions

diff --git a/docs/tutorials/001/acceptor.h b/docs/tutorials/001/acceptor.h
index 988b1948231..094e68acdf5 100644
--- a/docs/tutorials/001/acceptor.h
+++ b/docs/tutorials/001/acceptor.h
@@ -2,7 +2,7 @@
 // $Id$
 
 
-#if !defined (_CLIENT_ACCEPTOR_H)
+#ifndef _CLIENT_ACCEPTOR_H
 #define _CLIENT_ACCEPTOR_H
 
 /*
@@ -11,6 +11,10 @@
  */
 #include "ace/SOCK_Acceptor.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
   An Event_Handler is what you register with ACE_Reactor.  When events occur,
   the reactor will callback on the Event_Handler.  More on that in a few lines.
@@ -72,7 +76,7 @@ public:
      */
     return _reactor->register_handler( this, ACE_Event_Handler::ACCEPT_MASK );
   }
-  
+
 private:
 
   /*
@@ -84,8 +88,8 @@ private:
     acceptor object, so that's what we provide.
    */
   ACE_HANDLE get_handle (void) const
-  { 
-    return this->peer_acceptor_.get_handle (); 
+  {
+    return this->peer_acceptor_.get_handle ();
   }
 
   /*
@@ -100,7 +104,7 @@ private:
       disconnects.
      */
     Logging_Handler *svc_handler = new Logging_Handler;
-  
+
     /*
       To complete the connection, we invoke the accept() method call on
       the acceptor object and provide it with the connection handler instance.
@@ -117,7 +121,7 @@ private:
      */
     if (svc_handler->open (reactor_) == -1)
       svc_handler->close ();
-  
+
     return 0;
   }
 
@@ -126,7 +130,7 @@ protected:
   /*
     Our acceptor object instance
    */
-  ACE_SOCK_Acceptor peer_acceptor_;     
+  ACE_SOCK_Acceptor peer_acceptor_;
 
   /*
     A place to remember our reactor pointer
diff --git a/docs/tutorials/001/logger.h b/docs/tutorials/001/logger.h
index 8063f83f48a..6e46176fd6e 100644
--- a/docs/tutorials/001/logger.h
+++ b/docs/tutorials/001/logger.h
@@ -2,7 +2,7 @@
 // $Id$
 
 
-#if !defined (_CLIENT_HANDLER_H)
+#ifndef _CLIENT_HANDLER_H
 #define _CLIENT_HANDLER_H
 
 /*
@@ -11,6 +11,10 @@
  */
 #include "ace/Event_Handler.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/INET_Addr.h"
 
 /*
@@ -92,7 +96,7 @@ protected:
      */
     char buf[128];
     memset(buf,0,sizeof(buf));
-    
+
     /*
       Invoke the recv() method of the ACE_SOCK_Stream to get some data.  It will
       return -1 if there is an error.  Otherwise, it will return the number of bytes
@@ -114,7 +118,7 @@ protected:
     default:
       ACE_DEBUG ((LM_DEBUG, "(%P|%t) from client: %s",buf));
     }
-  
+
     return 0;
   }
 
@@ -139,7 +143,7 @@ protected:
       Since we know we were dynamically allocated by the acceptor, now is a good
       time to get rid of ourselves.
      */
-    delete this;    
+    delete this;
 
     return 0;
   }
@@ -149,7 +153,7 @@ protected:
   /*
     Our peer connection.
    */
-  ACE_SOCK_Stream cli_stream_; 
+  ACE_SOCK_Stream cli_stream_;
 
   /*
     Our reactor (and our acceptor's reactor).
diff --git a/docs/tutorials/002/handler.h b/docs/tutorials/002/handler.h
index e7796cbb47b..a66ccccb9e6 100644
--- a/docs/tutorials/002/handler.h
+++ b/docs/tutorials/002/handler.h
@@ -5,6 +5,11 @@
 #define LOGGING_HANDLER_H
 
 #include "ace/INET_Addr.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Stream.h"
 #include "ace/Reactor.h"
 
diff --git a/docs/tutorials/005/client_acceptor.h b/docs/tutorials/005/client_acceptor.h
index 82416fa999c..fa3d3b41be8 100644
--- a/docs/tutorials/005/client_acceptor.h
+++ b/docs/tutorials/005/client_acceptor.h
@@ -7,17 +7,21 @@
 /*
    The ACE_Acceptor<> template lives in the ace/Acceptor.h header file. You'll
    find a very consitent naming convention between the ACE objects and the
-   headers where they can be found.  In general, the ACE object ACE_Foobar will 
+   headers where they can be found.  In general, the ACE object ACE_Foobar will
 
 
-   be found in ace/Foobar.h.   
+   be found in ace/Foobar.h.
  */
 
 #include "ace/Acceptor.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
    Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the
-   clients to connect to us.   
+   clients to connect to us.
  */
 #include "ace/SOCK_Acceptor.h"
 
@@ -25,7 +29,7 @@
    The Client_Handler object we develop will be used to handle clients once
    they're connected.  The ACE_Acceptor<> template's first parameter requires
    such an object.  In some cases, you can get by with just a forward
-   declaration on the class, in others you have to have the whole thing.   
+   declaration on the class, in others you have to have the whole thing.
  */
 #include "client_handler.h"
 
@@ -34,7 +38,7 @@
    connection attempts and create Client_Handler objects when they happen. In
    Tutorial 001, we wrote the basic acceptor logic on our own before we
    realized that ACE_Acceptor<> was available.  You'll get spoiled using the
-   ACE templates because they take away a lot of the tedious details!   
+   ACE templates because they take away a lot of the tedious details!
  */
 typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor;
 
diff --git a/docs/tutorials/005/client_handler.h b/docs/tutorials/005/client_handler.h
index bdd8d903f6f..b1e4af021d3 100644
--- a/docs/tutorials/005/client_handler.h
+++ b/docs/tutorials/005/client_handler.h
@@ -8,22 +8,27 @@
    Our client handler must exist somewhere in the ACE_Event_Handler object
    hierarchy.  This is a requirement of the ACE_Reactor because it maintains
    ACE_Event_Handler pointers for each registered event handler.  You could
-   derive our Client_Handler directly from ACE_Event_Handler but you still have 
+   derive our Client_Handler directly from ACE_Event_Handler but you still have
    to have an ACE_SOCK_Stream for the actually connection.  With a direct
    derivative of ACE_Event_Handler, you'll have to contain and maintain an
    ACE_SOCK_Stream instance yourself.  With ACE_Svc_Handler (which is a
    derivative of ACE_Event_Handler) some of those details are handled for you.
-    
+
  */
 
 #include "ace/Svc_Handler.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Stream.h"
 
 /*
-   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> 
+   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<>
    interface as well.  That's what the ACE_NULL_SYNCH parameter below is all
    about.  That's beyond our scope here but we'll come back to it in the next
-   tutorial when we start looking at concurrency options.   
+   tutorial when we start looking at concurrency options.
  */
 class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH >
 {
@@ -38,20 +43,20 @@ public:
      intuitive (at least to me).  Instead, we provide a new method of
      destruction and we make our destructor protected so that only ourselves,
      our derivatives and our friends can delete us. It's a nice
-     compromise.   
+     compromise.
    */
   void destroy (void);
 
   /*
      Most ACE objects have an open() method.  That's how you make them ready
-     to do work.  ACE_Event_Handler has a virtual open() method which allows us 
+     to do work.  ACE_Event_Handler has a virtual open() method which allows us
      to create this overrride.  ACE_Acceptor<> will invoke this method after
      creating a new Client_Handler when a client connects. Notice that the
      parameter to open() is a void*.  It just so happens that the pointer
-     points to the acceptor which created us.  You would like for the parameter 
+     points to the acceptor which created us.  You would like for the parameter
      to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that
      would tie it too closely to the ACE_Acceptor<> set of objects.  In our
-     definition of open() you'll see how we get around that.   
+     definition of open() you'll see how we get around that.
    */
   int open (void *_acceptor);
 
@@ -62,8 +67,8 @@ public:
      clean itself up. Since an event handler can be registered for more than
      one type of callback, the callback mask is provided to inform
      handle_close() exactly which method failed.  That way, you don't have to
-     maintain state information between your handle_* method calls. The _handle 
-     parameter is explained below...   
+     maintain state information between your handle_* method calls. The _handle
+     parameter is explained below...
    */
   int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask);
 
@@ -78,7 +83,7 @@ protected:
      maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for
      us.  However, if we had been derived directly from ACE_Event_Handler, we
      may have chosen not to contain the peer.  In that case, the _handleg
-     would be important to us for reading the client's data.   
+     would be important to us for reading the client's data.
    */
   int handle_input (ACE_HANDLE _handle);
 
@@ -87,15 +92,15 @@ protected:
      function which I will call from handle_input().  That allows me to
      introduce concurrencly in later tutorials with a no changes to the worker
      function.  You can think of process() as application-level code and
-     everything elase as application-framework code.   
+     everything elase as application-framework code.
    */
   int process (char *_rdbuf, int _rdbuf_len);
 
   /*
      We don't really do anything in our destructor but we've declared it to be
      protected to prevent casual deletion of this object.  As I said above, I
-     really would prefer that everyone goes through the destroy() method to get 
-     rid of us.   
+     really would prefer that everyone goes through the destroy() method to get
+     rid of us.
    */
    ~Client_Handler (void);
 };
diff --git a/docs/tutorials/006/client_acceptor.h b/docs/tutorials/006/client_acceptor.h
index b0944f3a316..2318b6adacd 100644
--- a/docs/tutorials/006/client_acceptor.h
+++ b/docs/tutorials/006/client_acceptor.h
@@ -7,17 +7,21 @@
 /*
    The ACE_Acceptor<> template lives in the ace/Acceptor.h header file. You'll
    find a very consitent naming convention between the ACE objects and the
-   headers where they can be found.  In general, the ACE object ACE_Foobar will 
+   headers where they can be found.  In general, the ACE object ACE_Foobar will
 
 
-   be found in ace/Foobar.h.   
+   be found in ace/Foobar.h.
  */
 
 #include "ace/Acceptor.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
    Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the
-   clients to connect to us.   
+   clients to connect to us.
  */
 #include "ace/SOCK_Acceptor.h"
 
@@ -25,7 +29,7 @@
    The Client_Handler object we develop will be used to handle clients once
    they're connected.  The ACE_Acceptor<> template's first parameter requires
    such an object.  In some cases, you can get by with just a forward
-   declaration on the class, in others you have to have the whole thing.   
+   declaration on the class, in others you have to have the whole thing.
  */
 #include "client_handler.h"
 
@@ -34,7 +38,7 @@
    connection attempts and create Client_Handler objects when they happen. In
    Tutorial 001, we wrote the basic acceptor logic on our own before we
    realized that ACE_Acceptor<> was available.  You'll get spoiled using the
-   ACE templates because they take away a lot of the tedious details!   
+   ACE templates because they take away a lot of the tedious details!
  */
 typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base;
 
@@ -49,32 +53,32 @@ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base;
 class Client_Acceptor : public Client_Acceptor_Base
 {
 public:
-	/*
-	   This is always a good idea.  If nothing else, it makes your code more
-	   orthogonal no matter what baseclasses your objects have.
-	 */
-	typedef Client_Acceptor_Base inherited;
-
-	/*
-	   Construct the object with the concurrency strategy.  Since this tutorial
-	   is focused on thread-per-connection, we make that the default.  We could
-	   have chosen to omitt the default and populate it in main() instead.
-	 */
-	Client_Acceptor( int _thread_per_connection = 1 )
-	 : thread_per_connection_(_thread_per_connection)
-	{
-	}
-
-	/*
-	   Return the value of our strategy flag.  This is used by the Client_Handler
-	   to decide how to act.  If 'true' then the handler will behave in a
-	   thread-per-connection manner.
-	 */
-	int thread_per_connection(void)
-		{ return this->thread_per_connection_; }
+        /*
+           This is always a good idea.  If nothing else, it makes your code more
+           orthogonal no matter what baseclasses your objects have.
+         */
+        typedef Client_Acceptor_Base inherited;
+
+        /*
+           Construct the object with the concurrency strategy.  Since this tutorial
+           is focused on thread-per-connection, we make that the default.  We could
+           have chosen to omitt the default and populate it in main() instead.
+         */
+        Client_Acceptor( int _thread_per_connection = 1 )
+         : thread_per_connection_(_thread_per_connection)
+        {
+        }
+
+        /*
+           Return the value of our strategy flag.  This is used by the Client_Handler
+           to decide how to act.  If 'true' then the handler will behave in a
+           thread-per-connection manner.
+         */
+        int thread_per_connection(void)
+                { return this->thread_per_connection_; }
 
 protected:
-	int thread_per_connection_;
+        int thread_per_connection_;
 
 };
 
diff --git a/docs/tutorials/006/client_handler.h b/docs/tutorials/006/client_handler.h
index d80c23e942d..83a4c326b94 100644
--- a/docs/tutorials/006/client_handler.h
+++ b/docs/tutorials/006/client_handler.h
@@ -8,19 +8,24 @@
    Our client handler must exist somewhere in the ACE_Event_Handler object
    hierarchy.  This is a requirement of the ACE_Reactor because it maintains
    ACE_Event_Handler pointers for each registered event handler.  You could
-   derive our Client_Handler directly from ACE_Event_Handler but you still have 
+   derive our Client_Handler directly from ACE_Event_Handler but you still have
    to have an ACE_SOCK_Stream for the actually connection.  With a direct
    derivative of ACE_Event_Handler, you'll have to contain and maintain an
    ACE_SOCK_Stream instance yourself.  With ACE_Svc_Handler (which is a
    derivative of ACE_Event_Handler) some of those details are handled for you.
-    
+
  */
 
 #include "ace/Svc_Handler.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Stream.h"
 
 /*
-   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> 
+   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<>
    interface as well.  That's what the ACE_NULL_SYNCH parameter below is all
    about.  If our Client_Acceptor has chosen thread-per-connection then our
    open() method will activate us into a thread.  At that point, our svc()
@@ -42,27 +47,27 @@ public:
      intuitive (at least to me).  Instead, we provide a new method of
      destruction and we make our destructor protected so that only ourselves,
      our derivatives and our friends can delete us. It's a nice
-     compromise.   
+     compromise.
    */
   void destroy (void);
 
   /*
      Most ACE objects have an open() method.  That's how you make them ready
-     to do work.  ACE_Event_Handler has a virtual open() method which allows us 
+     to do work.  ACE_Event_Handler has a virtual open() method which allows us
      to create this overrride.  ACE_Acceptor<> will invoke this method after
      creating a new Client_Handler when a client connects. Notice that the
      parameter to open() is a void*.  It just so happens that the pointer
-     points to the acceptor which created us.  You would like for the parameter 
+     points to the acceptor which created us.  You would like for the parameter
      to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that
      would tie it too closely to the ACE_Acceptor<> set of objects.  In our
-     definition of open() you'll see how we get around that.   
+     definition of open() you'll see how we get around that.
    */
   int open (void *_acceptor);
 
   /*
      When an ACE_Task<> object falls out of the svc() method, the framework
-	 will call the close() method.  That's where we want to cleanup ourselves
-	 if we're running in either thread-per-connection or thread-pool mode.
+         will call the close() method.  That's where we want to cleanup ourselves
+         if we're running in either thread-per-connection or thread-pool mode.
    */
   int close(u_long flags = 0);
 
@@ -73,8 +78,8 @@ public:
      clean itself up. Since an event handler can be registered for more than
      one type of callback, the callback mask is provided to inform
      handle_close() exactly which method failed.  That way, you don't have to
-     maintain state information between your handle_* method calls. The _handle 
-     parameter is explained below...   
+     maintain state information between your handle_* method calls. The _handle
+     parameter is explained below...
    */
   int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask);
 
@@ -97,7 +102,7 @@ protected:
      maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for
      us.  However, if we had been derived directly from ACE_Event_Handler, we
      may have chosen not to contain the peer.  In that case, the _handleg
-     would be important to us for reading the client's data.   
+     would be important to us for reading the client's data.
    */
   int handle_input (ACE_HANDLE _handle);
 
@@ -112,8 +117,8 @@ protected:
   /*
      We don't really do anything in our destructor but we've declared it to be
      protected to prevent casual deletion of this object.  As I said above, I
-     really would prefer that everyone goes through the destroy() method to get 
-     rid of us.   
+     really would prefer that everyone goes through the destroy() method to get
+     rid of us.
    */
    ~Client_Handler (void);
 };
diff --git a/docs/tutorials/007/client_acceptor.h b/docs/tutorials/007/client_acceptor.h
index e1c0eded6fd..82c761879ea 100644
--- a/docs/tutorials/007/client_acceptor.h
+++ b/docs/tutorials/007/client_acceptor.h
@@ -7,15 +7,19 @@
 /*
    The ACE_Acceptor<> template lives in the ace/Acceptor.h header file. You'll
    find a very consitent naming convention between the ACE objects and the
-   headers where they can be found.  In general, the ACE object ACE_Foobar will 
-   be found in ace/Foobar.h.   
+   headers where they can be found.  In general, the ACE object ACE_Foobar will
+   be found in ace/Foobar.h.
  */
 
 #include "ace/Acceptor.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
    Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the
-   clients to connect to us.   
+   clients to connect to us.
  */
 #include "ace/SOCK_Acceptor.h"
 
@@ -23,7 +27,7 @@
    The Client_Handler object we develop will be used to handle clients once
    they're connected.  The ACE_Acceptor<> template's first parameter requires
    such an object.  In some cases, you can get by with just a forward
-   declaration on the class, in others you have to have the whole thing.   
+   declaration on the class, in others you have to have the whole thing.
  */
 #include "client_handler.h"
 
@@ -32,7 +36,7 @@
    connection attempts and create Client_Handler objects when they happen. In
    Tutorial 001, we wrote the basic acceptor logic on our own before we
    realized that ACE_Acceptor<> was available.  You'll get spoiled using the
-   ACE templates because they take away a lot of the tedious details!   
+   ACE templates because they take away a lot of the tedious details!
  */
 typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base;
 
@@ -57,81 +61,81 @@ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base;
 class Client_Acceptor : public Client_Acceptor_Base
 {
 public:
-	typedef Client_Acceptor_Base inherited;
-
-	/*
-	   Now that we have more than two strategies, we need more than a boolean
-	   to tell us what we're using.  A set of enums is a good choice because
-	   it allows us to use named values.  Another option would be a set of
-	   static const integers.
-	 */
-	enum concurrency_t
-	{
-		single_threaded_,
-		thread_per_connection_,
-		thread_pool_
-	};
-
-	/*
-	    The default constructor allows the programmer to choose the concurrency
-		strategy.  Since we want to focus on thread-pool, that's what we'll use
-		if nothing is specified.
-	 */
-	Client_Acceptor( int _concurrency = thread_pool_ );
-
-	/*
-	    Another option is to construct the object with an existing thread pool.
-		The  concurrency strategy is pretty obvious at that point.
-	 */
-	Client_Acceptor( Thread_Pool & _thread_pool );
-
-	/*
-	    Our destructor will take care of shutting down the thread-pool
-		if applicable.
-	 */
-	~Client_Acceptor( void );
-
-	/*
-	    Open ourselves and register with the given reactor.  The thread pool size
-		can be specified here if you want to use that concurrency strategy.
-	 */
-	int open( const ACE_INET_Addr & _addr, ACE_Reactor * _reactor,
-		int _pool_size = Thread_Pool::default_pool_size_ );
-
-	/*
-	    Close ourselves and our thread pool if applicable
-	 */
-	int close(void);
-
-	/*
-	   What is our concurrency strategy?
-	 */
-	int concurrency(void)
-		{ return this->concurrency_; }
-
-	/*
-	    Give back a pointer to our thread pool.  Our Client_Handler objects
-		will need this so that their handle_input() methods can put themselves
-		into the pool.  Another alternative would be a globally accessible
-		thread pool.  ACE_Singleton<> is a way to achieve that.
-	 */
-	Thread_Pool * thread_pool(void)
-		{ return & this->the_thread_pool_; }
-
-	/*
-	   Since we can be constructed with a Thread_Pool reference, there are times
-	   when we need to know if the thread pool we're using is ours or if we're
-	   just borrowing it from somebody else.
-	 */
-	int thread_pool_is_private(void)
-		{ return &the_thread_pool_ == &private_thread_pool_; }
+        typedef Client_Acceptor_Base inherited;
+
+        /*
+           Now that we have more than two strategies, we need more than a boolean
+           to tell us what we're using.  A set of enums is a good choice because
+           it allows us to use named values.  Another option would be a set of
+           static const integers.
+         */
+        enum concurrency_t
+        {
+                single_threaded_,
+                thread_per_connection_,
+                thread_pool_
+        };
+
+        /*
+            The default constructor allows the programmer to choose the concurrency
+                strategy.  Since we want to focus on thread-pool, that's what we'll use
+                if nothing is specified.
+         */
+        Client_Acceptor( int _concurrency = thread_pool_ );
+
+        /*
+            Another option is to construct the object with an existing thread pool.
+                The  concurrency strategy is pretty obvious at that point.
+         */
+        Client_Acceptor( Thread_Pool & _thread_pool );
+
+        /*
+            Our destructor will take care of shutting down the thread-pool
+                if applicable.
+         */
+        ~Client_Acceptor( void );
+
+        /*
+            Open ourselves and register with the given reactor.  The thread pool size
+                can be specified here if you want to use that concurrency strategy.
+         */
+        int open( const ACE_INET_Addr & _addr, ACE_Reactor * _reactor,
+                int _pool_size = Thread_Pool::default_pool_size_ );
+
+        /*
+            Close ourselves and our thread pool if applicable
+         */
+        int close(void);
+
+        /*
+           What is our concurrency strategy?
+         */
+        int concurrency(void)
+                { return this->concurrency_; }
+
+        /*
+            Give back a pointer to our thread pool.  Our Client_Handler objects
+                will need this so that their handle_input() methods can put themselves
+                into the pool.  Another alternative would be a globally accessible
+                thread pool.  ACE_Singleton<> is a way to achieve that.
+         */
+        Thread_Pool * thread_pool(void)
+                { return & this->the_thread_pool_; }
+
+        /*
+           Since we can be constructed with a Thread_Pool reference, there are times
+           when we need to know if the thread pool we're using is ours or if we're
+           just borrowing it from somebody else.
+         */
+        int thread_pool_is_private(void)
+                { return &the_thread_pool_ == &private_thread_pool_; }
 
 protected:
-	int concurrency_;
+        int concurrency_;
 
-	Thread_Pool   private_thread_pool_;
+        Thread_Pool   private_thread_pool_;
 
-	Thread_Pool & the_thread_pool_;
+        Thread_Pool & the_thread_pool_;
 };
 
 #endif // CLIENT_ACCEPTOR_H
diff --git a/docs/tutorials/007/client_handler.h b/docs/tutorials/007/client_handler.h
index 340cde65a4d..57fd5e033d2 100644
--- a/docs/tutorials/007/client_handler.h
+++ b/docs/tutorials/007/client_handler.h
@@ -8,7 +8,7 @@
    Our client handler must exist somewhere in the ACE_Event_Handler object
    hierarchy.  This is a requirement of the ACE_Reactor because it maintains
    ACE_Event_Handler pointers for each registered event handler.  You could
-   derive our Client_Handler directly from ACE_Event_Handler but you still have 
+   derive our Client_Handler directly from ACE_Event_Handler but you still have
    to have an ACE_SOCK_Stream for the actually connection.  With a direct
    derivative of ACE_Event_Handler, you'll have to contain and maintain an
    ACE_SOCK_Stream instance yourself.  With ACE_Svc_Handler (which is a
@@ -16,16 +16,21 @@
  */
 
 #include "ace/Svc_Handler.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Stream.h"
 
 class Client_Acceptor;
 class Thread_Pool;
 
 /*
-   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> 
+   Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<>
    interface as well.  That's what the ACE_NULL_SYNCH parameter below is all
    about.  That's beyond our scope here but we'll come back to it in the next
-   tutorial when we start looking at concurrency options.   
+   tutorial when we start looking at concurrency options.
  */
 class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH >
 {
@@ -41,27 +46,27 @@ public:
      intuitive (at least to me).  Instead, we provide a new method of
      destruction and we make our destructor protected so that only ourselves,
      our derivatives and our friends can delete us. It's a nice
-     compromise.   
+     compromise.
    */
   void destroy (void);
 
   /*
      Most ACE objects have an open() method.  That's how you make them ready
-     to do work.  ACE_Event_Handler has a virtual open() method which allows us 
+     to do work.  ACE_Event_Handler has a virtual open() method which allows us
      to create this overrride.  ACE_Acceptor<> will invoke this method after
      creating a new Client_Handler when a client connects. Notice that the
      parameter to open() is a void*.  It just so happens that the pointer
-     points to the acceptor which created us.  You would like for the parameter 
+     points to the acceptor which created us.  You would like for the parameter
      to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that
      would tie it too closely to the ACE_Acceptor<> set of objects.  In our
-     definition of open() you'll see how we get around that.   
+     definition of open() you'll see how we get around that.
    */
   int open (void *_acceptor);
 
   /*
      When an ACE_Task<> object falls out of the svc() method, the framework
-	 will call the close() method.  That's where we want to cleanup ourselves
-	 if we're running in either thread-per-connection or thread-pool mode.
+         will call the close() method.  That's where we want to cleanup ourselves
+         if we're running in either thread-per-connection or thread-pool mode.
    */
   int close(u_long flags = 0);
 
@@ -72,8 +77,8 @@ public:
      clean itself up. Since an event handler can be registered for more than
      one type of callback, the callback mask is provided to inform
      handle_close() exactly which method failed.  That way, you don't have to
-     maintain state information between your handle_* method calls. The _handle 
-     parameter is explained below...   
+     maintain state information between your handle_* method calls. The _handle
+     parameter is explained below...
    */
   int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask);
 
@@ -86,7 +91,7 @@ public:
      maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for
      us.  However, if we had been derived directly from ACE_Event_Handler, we
      may have chosen not to contain the peer.  In that case, the _handleg
-     would be important to us for reading the client's data.   
+     would be important to us for reading the client's data.
    */
   int handle_input (ACE_HANDLE _handle);
 
@@ -105,39 +110,39 @@ protected:
      function which I will call from handle_input().  That allows me to
      introduce concurrencly in later tutorials with a no changes to the worker
      function.  You can think of process() as application-level code and
-     everything elase as application-framework code.   
+     everything elase as application-framework code.
    */
   int process (char *_rdbuf, int _rdbuf_len);
 
   /*
      We don't really do anything in our destructor but we've declared it to be
      protected to prevent casual deletion of this object.  As I said above, I
-     really would prefer that everyone goes through the destroy() method to get 
-     rid of us.   
+     really would prefer that everyone goes through the destroy() method to get
+     rid of us.
    */
    ~Client_Handler (void);
 
    /*
       When we get to the definition of Client_Handler we'll see that there are
-	  several places where we go back to the Client_Acceptor for information.
-	  It is generally a good idea to do that through an accesor rather than
-	  using the member variable directly.
+          several places where we go back to the Client_Acceptor for information.
+          It is generally a good idea to do that through an accesor rather than
+          using the member variable directly.
     */
    Client_Acceptor * client_acceptor( void )
-   		{ return this->client_acceptor_; }
+                { return this->client_acceptor_; }
 
    /*
       And since you shouldn't access a member variable directly, neither should you
-	  set (mutate) it.  Although it might seem silly to do it this way, you'll thank
-	  yourself for it later.
+          set (mutate) it.  Although it might seem silly to do it this way, you'll thank
+          yourself for it later.
     */
    void client_acceptor( Client_Acceptor * _client_acceptor )
-   		{ this->client_acceptor_ = _client_acceptor; }
+                { this->client_acceptor_ = _client_acceptor; }
 
    /*
       The concurrency() accessor tells us the current concurrency strategy.  It actually
-	  queries the Client_Acceptor for it but by having the accessor in place, we could
-	  change our implementation without affecting everything that needs to know.
+          queries the Client_Acceptor for it but by having the accessor in place, we could
+          change our implementation without affecting everything that needs to know.
     */
    int concurrency(void);
 
@@ -151,12 +156,12 @@ protected:
 
    /*
       For some reason I didn't create accessor/mutator methods for this.  So much for
-	  consistency....
+          consistency....
 
-	  This variable is used to remember the thread in which we were created:  the "creator"
-	  thread in other words.  handle_input() needs to know if it is operating in the
-	  main reactor thread (which is the one that created us) or if it is operating in
-	  one of the thread pool threads.  More on this when we get to handle_input().
+          This variable is used to remember the thread in which we were created:  the "creator"
+          thread in other words.  handle_input() needs to know if it is operating in the
+          main reactor thread (which is the one that created us) or if it is operating in
+          one of the thread pool threads.  More on this when we get to handle_input().
     */
    ACE_thread_t      creator_;
 };
diff --git a/docs/tutorials/007/thread_pool.h b/docs/tutorials/007/thread_pool.h
index ebf2e162ce4..0897b1d47af 100644
--- a/docs/tutorials/007/thread_pool.h
+++ b/docs/tutorials/007/thread_pool.h
@@ -10,6 +10,10 @@
  */
 #include "ace/Task.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
    We need a forward reference for ACE_Event_Handler so that our enqueue() method
    can accept a pointer to one.
@@ -29,38 +33,38 @@ public:
 
   typedef ACE_Task<ACE_MT_SYNCH> inherited;
 
-	/*
-	   Provide an enumeration for the default pool size.  By doing this, other objects
-	   can use the value when they want a default.
-	 */
-	enum size_t
-	{
-	  default_pool_size_ = 5
-	};
+        /*
+           Provide an enumeration for the default pool size.  By doing this, other objects
+           can use the value when they want a default.
+         */
+        enum size_t
+        {
+          default_pool_size_ = 5
+        };
 
-	// Basic constructor
-	Thread_Pool(void);
+        // Basic constructor
+        Thread_Pool(void);
 
-	/*
-	   Opening the thread pool causes one or more threads to be activated.  When activated,
-	   they all execute the svc() method declared below.
-	 */
-	int open( int _pool_size = default_pool_size_ );
+        /*
+           Opening the thread pool causes one or more threads to be activated.  When activated,
+           they all execute the svc() method declared below.
+         */
+        int open( int _pool_size = default_pool_size_ );
 
     /*
        Some compilers will complain that our open() above attempts to
        override a virtual function in the baseclass.  We have no
        intention of overriding that method but in order to keep the
-       compiler quiet we have to add this method as a pass-thru to the 
+       compiler quiet we have to add this method as a pass-thru to the
        baseclass method.
     */
-	virtual int open(void * _void_data)
-		{ return inherited::open(_void_data); }
+        virtual int open(void * _void_data)
+                { return inherited::open(_void_data); }
 
-	/*
-	   When you're done wit the thread pool, you have to have some way to shut it down.
-	   This is what close() is for.
-	 */
+        /*
+           When you're done wit the thread pool, you have to have some way to shut it down.
+           This is what close() is for.
+         */
     int close( void );
 
     /*
@@ -70,38 +74,38 @@ public:
     virtual int close( u_long flags )
         { return inherited::close(flags); }
 
-	/*
-	   To use the thread pool, you have to put some unit of work into it.  Since we're
-	   dealing with event handlers (or at least their derivatives), I've chosen to provide
-	   an enqueue() method that takes a pointer to an ACE_Event_Handler.  The handler's
-	   handle_input() method will be called, so your object has to know when it is being
-	   called by the thread pool.
-	 */
-	int enqueue( ACE_Event_Handler * _handler );
-
-	/*
-	   Another handy ACE template is ACE_Atomic_Op<>.  When parameterized, this allows
-	   is to have a thread-safe counting object.  The typical arithmetic operators are
-	   all internally thread-safe so that you can share it across threads without worrying
-	   about any contention issues.
-	 */
-	typedef ACE_Atomic_Op<ACE_Mutex,int> counter_t;
+        /*
+           To use the thread pool, you have to put some unit of work into it.  Since we're
+           dealing with event handlers (or at least their derivatives), I've chosen to provide
+           an enqueue() method that takes a pointer to an ACE_Event_Handler.  The handler's
+           handle_input() method will be called, so your object has to know when it is being
+           called by the thread pool.
+         */
+        int enqueue( ACE_Event_Handler * _handler );
+
+        /*
+           Another handy ACE template is ACE_Atomic_Op<>.  When parameterized, this allows
+           is to have a thread-safe counting object.  The typical arithmetic operators are
+           all internally thread-safe so that you can share it across threads without worrying
+           about any contention issues.
+         */
+        typedef ACE_Atomic_Op<ACE_Mutex,int> counter_t;
 
 protected:
 
-	/*
-	   Our svc() method will dequeue the enqueued event handler objects and invoke the
-	   handle_input() method on each.  Since we're likely running in more than one thread,
-	   idle threads can take work from the queue while other threads are busy executing
-	   handle_input() on some object.
-	 */
-	int svc(void);
-
-	/*
-	   We use the atomic op to keep a count of the number of threads in which our svc()
-	   method is running.  This is particularly important when we want to close() it down!
-	 */
-	counter_t active_threads_;
+        /*
+           Our svc() method will dequeue the enqueued event handler objects and invoke the
+           handle_input() method on each.  Since we're likely running in more than one thread,
+           idle threads can take work from the queue while other threads are busy executing
+           handle_input() on some object.
+         */
+        int svc(void);
+
+        /*
+           We use the atomic op to keep a count of the number of threads in which our svc()
+           method is running.  This is particularly important when we want to close() it down!
+         */
+        counter_t active_threads_;
 };
 
 #endif // THREAD_POOL_H
diff --git a/docs/tutorials/010/block.h b/docs/tutorials/010/block.h
index 662c3c1e536..583886872cb 100644
--- a/docs/tutorials/010/block.h
+++ b/docs/tutorials/010/block.h
@@ -6,8 +6,12 @@
 
 #include "ace/Message_Block.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
-   This simple ACE_Message_Block derivative will inform us of it's construction 
+   This simple ACE_Message_Block derivative will inform us of it's construction
    and destruction.  We'll use this to assure ourselves that we don't have any
    memory leaks.  In a real application, of course, this isn't necessary.
  */
diff --git a/docs/tutorials/010/task.h b/docs/tutorials/010/task.h
index 9f242c124dd..2aecb429c03 100644
--- a/docs/tutorials/010/task.h
+++ b/docs/tutorials/010/task.h
@@ -6,6 +6,10 @@
 
 #include "ace/Task.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
   Like the thread-pool server tutorial, we'll derive from ACE_Task<>.
   Our goal here is to show off the ACE_Message_Queue and the best way
@@ -17,7 +21,7 @@ class Task : public ACE_Task < ACE_MT_SYNCH >
 public:
 
   typedef ACE_Task < ACE_MT_SYNCH > inherited;
-    
+
     /*
       The constructor/destructor are simple but take care of some
       necessary housekeeping.
diff --git a/docs/tutorials/011/block.h b/docs/tutorials/011/block.h
index bfd49d723f7..1ffc5cb4e9d 100644
--- a/docs/tutorials/011/block.h
+++ b/docs/tutorials/011/block.h
@@ -6,6 +6,10 @@
 
 #include "ace/Message_Block.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 class Block : public ACE_Message_Block
 {
 public:
diff --git a/docs/tutorials/011/task.h b/docs/tutorials/011/task.h
index 436326c68a0..8646fac1a7c 100644
--- a/docs/tutorials/011/task.h
+++ b/docs/tutorials/011/task.h
@@ -6,6 +6,10 @@
 
 #include "ace/Task.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 class Task : public ACE_Task < ACE_MT_SYNCH >
 {
 public:
diff --git a/docs/tutorials/012/data.h b/docs/tutorials/012/data.h
index 3c656608425..54e8e55e87c 100644
--- a/docs/tutorials/012/data.h
+++ b/docs/tutorials/012/data.h
@@ -6,6 +6,10 @@
 
 #include "ace/Message_Block.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
   We'll start by defining a basic unit of work that can be put into
   the message queue.  The threads in the pool will expect to find one
@@ -71,8 +75,8 @@ protected:
 
 /*
   We derive a Message_Block from ACE_Message_Block and teach it about
-  our Unit_Of_Work object.  When our task's svc() method pulls a block 
-  out of the queue, it can then invoke the virtual methods of the work 
+  our Unit_Of_Work object.  When our task's svc() method pulls a block
+  out of the queue, it can then invoke the virtual methods of the work
   object safely.  In this implementation we've also retained the
   original ACE_Message_Block functionallity so that we can use the
   underlying ACE_Data_Block objects to store data other than our
@@ -96,7 +100,7 @@ public:
             ACE_DEBUG ((LM_DEBUG, "(%P|%t) Message_Block ctor 0x%x for 0x%x\n", (void *) this, data_));
         }
 
-	~Message_Block(void)
+        ~Message_Block(void)
         {
             ACE_DEBUG ((LM_DEBUG, "(%P|%t) Message_Block dtor 0x%x for 0x%x\n", (void *) this, data_));
             delete data_;
diff --git a/docs/tutorials/012/task.h b/docs/tutorials/012/task.h
index 52dcf022b3e..877ac98ede5 100644
--- a/docs/tutorials/012/task.h
+++ b/docs/tutorials/012/task.h
@@ -6,6 +6,10 @@
 
 #include "ace/Task.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /*
   This is our basic thread-pool Task.  We have a choice of pool size
   on the open() and the usual svc() and close() methods.
diff --git a/docs/tutorials/013/block.h b/docs/tutorials/013/block.h
index 40a31bd1b07..26604a57e4c 100644
--- a/docs/tutorials/013/block.h
+++ b/docs/tutorials/013/block.h
@@ -5,6 +5,11 @@
 #define BLOCK_H
 
 #include "ace/Message_Block.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/Synch.h"
 #include "mld.h"
 #include "work.h"
@@ -16,7 +21,7 @@
    out of scope unexpectedly.  An ACE_Message_Block will be deleted as soon as
    it's release() method is called but the ACE_Data_Blocks it uses are
    reference counted and only delete when the last reference release()es the
-   block.  We use that trait to simply our object memory management. 
+   block.  We use that trait to simply our object memory management.
  */
 class Data_Block : public ACE_Data_Block
 {
@@ -49,9 +54,9 @@ public:
      ~Lock (void);
 
     // When the Data_Block is destroyed, the Message_Block is
-    // holding a lock with this object.  If we were to destroy 
+    // holding a lock with this object.  If we were to destroy
     // the Lock with the Data_Block, we would have a
-    // segfault.  Instead, the Data_Block invokes destroy() to 
+    // segfault.  Instead, the Data_Block invokes destroy() to
     // mark the object as un-needed so that when the
     // Message_Block invokes release() to drop the lock, the
     // Lock can delete itself.
@@ -65,7 +70,7 @@ protected:
 
 /*
    This simple derivative of ACE_Message_Block will construct our Data_Block
-   object to contain a unit of work. 
+   object to contain a unit of work.
  */
 class Message_Block : public ACE_Message_Block
 {
diff --git a/docs/tutorials/013/mld.h b/docs/tutorials/013/mld.h
index a9ee1de02b4..7dbd982e863 100644
--- a/docs/tutorials/013/mld.h
+++ b/docs/tutorials/013/mld.h
@@ -5,13 +5,18 @@
 #define MLD_H
 
 #include "ace/Synch.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/Singleton.h"
 
 /*
    This is a cheap memory leak detector.  Each class I want to watch over
    contains an mld object.  The mld object's ctor increments a global counter
    while the dtor decrements it.  If the counter is non-zero when the program
-   is ready to exit then there may be a leak. 
+   is ready to exit then there may be a leak.
  */
 
 class mld
@@ -30,12 +35,12 @@ protected:
 
 /*
    Just drop 'MLD' anywhere in your class definition to get cheap memory leak
-   detection for your class. 
+   detection for your class.
  */
 #define MLD            mld mld_
 
 /*
-   Use 'MLD_COUNTER' in main() to see if things are OK. 
+   Use 'MLD_COUNTER' in main() to see if things are OK.
  */
 #define MLD_COUNTER    mld::value()
 
diff --git a/docs/tutorials/013/task.h b/docs/tutorials/013/task.h
index 0c813641169..8c11a8872c6 100644
--- a/docs/tutorials/013/task.h
+++ b/docs/tutorials/013/task.h
@@ -5,15 +5,20 @@
 #define TASK_H
 
 #include "ace/Task.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "mld.h"
 
 /*
-   This is much like the Task we've used in the past for implementing a  thread 
-   pool.  This time, however, I've made the Task an element in a  singly-linked 
+   This is much like the Task we've used in the past for implementing a  thread
+   pool.  This time, however, I've made the Task an element in a  singly-linked
    list.  As the svc() method finishes the process() on a  unit of work, it
    will enqueue that unit of work to the next_ Task if  there is one.  If the
    Task does not have a next_ Task, it will invoke the unit of work object's
-   fini() method after invoking process(). 
+   fini() method after invoking process().
  */
 class Task : public ACE_Task < ACE_MT_SYNCH >
 {
diff --git a/docs/tutorials/013/work.h b/docs/tutorials/013/work.h
index 26e10b96266..0cf60afd1ed 100644
--- a/docs/tutorials/013/work.h
+++ b/docs/tutorials/013/work.h
@@ -5,12 +5,17 @@
 #define WORK_H
 
 #include "ace/Log_Msg.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/Synch.h"
 #include "mld.h"
 
 /*
    Our specilized message queue and thread pool will know how to do "work" on
-   our Unit_Of_Work baseclass. 
+   our Unit_Of_Work baseclass.
  */
 class Unit_Of_Work
 {
@@ -42,7 +47,7 @@ protected:
 
 /*
    A fairly trivial work derivative that implements an equally trivial state
-   machine in process() 
+   machine in process()
  */
 class Work : public Unit_Of_Work
 {
diff --git a/docs/tutorials/014/EndTask.h b/docs/tutorials/014/EndTask.h
index e4ab823f1f9..1666c5e8869 100644
--- a/docs/tutorials/014/EndTask.h
+++ b/docs/tutorials/014/EndTask.h
@@ -22,9 +22,9 @@
 // your first module, and a Stream_Tail behind your
 // last module.
 //
-// If your put() a message to the Stream Tail, it 
+// If your put() a message to the Stream Tail, it
 // assumes you did so in error. This simple EndTask
-// class allows you to push a message to it and just 
+// class allows you to push a message to it and just
 // have it safely Go Away.
 //
 // All this Task does is release the Message_Block
@@ -39,33 +39,33 @@ public:
   typedef Task inherited;
 
   EndTask(const char *nameOfTask) :
-    inherited(nameOfTask, 0) { 
+    inherited(nameOfTask, 0) {
 
     // when we get open()'d, it with 0 threads
     // since there is actually no processing to do.
 
-	cerr << __LINE__ << " " << __FILE__ << endl;
+        cerr << __LINE__ << " " << __FILE__ << endl;
   };
 
   virtual int open(void *)
   {
-	cerr << __LINE__ << " " << __FILE__ << endl;
-	return 0;
+        cerr << __LINE__ << " " << __FILE__ << endl;
+        return 0;
   }
 
   virtual int open(void)
   {
-	cerr << __LINE__ << " " << __FILE__ << endl;
-	return 0;
+        cerr << __LINE__ << " " << __FILE__ << endl;
+        return 0;
   }
 
   virtual ~EndTask(void) {
   };
 
   virtual int put(ACE_Message_Block *message,
-		  ACE_Time_Value *timeout) {
+                  ACE_Time_Value *timeout) {
 
-	cerr << __LINE__ << " " << __FILE__ << endl;
+        cerr << __LINE__ << " " << __FILE__ << endl;
     ACE_UNUSED_ARG(timeout);
 
     // we don't have anything to do, so
diff --git a/docs/tutorials/014/Task.h b/docs/tutorials/014/Task.h
index e4797f49892..adb533c01ef 100644
--- a/docs/tutorials/014/Task.h
+++ b/docs/tutorials/014/Task.h
@@ -42,8 +42,8 @@ public:
   // This closes down the Task and all service threads.
 
   virtual int put(ACE_Message_Block *message,
-		  ACE_Time_Value *timeout);
-  // This is the interface that ACE_Stream uses to 
+                  ACE_Time_Value *timeout);
+  // This is the interface that ACE_Stream uses to
   // communicate with our Task.
 
   virtual int svc(void);
diff --git a/docs/tutorials/015/Client.h b/docs/tutorials/015/Client.h
index 63d22b03f73..c9f4e496bf2 100644
--- a/docs/tutorials/015/Client.h
+++ b/docs/tutorials/015/Client.h
@@ -5,6 +5,11 @@
 #define CLIENT_H
 
 #include "ace/SOCK_Stream.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "Protocol_Stream.h"
 
 class ACE_Message_Block;
@@ -41,11 +46,11 @@ public:
     int get( ACE_Message_Block * & _response );
 
 private:
-        // Protocol_Stream hides the protocol conformance details from 
+        // Protocol_Stream hides the protocol conformance details from
         // us.
     Protocol_Stream stream_;
 
-        // We create a connection on the peer_ and then pass ownership 
+        // We create a connection on the peer_ and then pass ownership
         // of it to the protocol stream.
     ACE_SOCK_Stream peer_;
 
@@ -54,7 +59,7 @@ private:
     const char * server_;
 
         // Accessors for the complex member variables.
-    
+
     Protocol_Stream & stream(void)
         {
             return this->stream_;
diff --git a/docs/tutorials/015/Compressor.h b/docs/tutorials/015/Compressor.h
index bc0257b16d1..4aaa83144ed 100644
--- a/docs/tutorials/015/Compressor.h
+++ b/docs/tutorials/015/Compressor.h
@@ -12,18 +12,18 @@
 class Compressor : public Protocol_Task
 {
 public:
-    
+
     typedef Protocol_Task inherited;
 
         // I've given you the option of creating this task derivative
-        // with a number of threads.  In retro-spect that really isn't 
+        // with a number of threads.  In retro-spect that really isn't
         // a good idea.  Most client/server systems rely on requests
-        // and responses happening in a predicatable order.  Introduce 
+        // and responses happening in a predicatable order.  Introduce
         // a thread pool and message queue and that ordering goes
         // right out the window.  In other words:  Don't ever use the
         // constructor parameter!
     Compressor( int _thr_count = 0 );
-    
+
     ~Compressor(void);
 
 protected:
diff --git a/docs/tutorials/015/Crypt.h b/docs/tutorials/015/Crypt.h
index 7a38e1bdb52..c7fb1d5948f 100644
--- a/docs/tutorials/015/Crypt.h
+++ b/docs/tutorials/015/Crypt.h
@@ -18,7 +18,7 @@ public:
         // Again we have the option of multiple threads and again I
         // regret tempting folks to use it.
     Crypt( int _thr_count = 0 );
-    
+
     ~Crypt(void);
 
 protected:
diff --git a/docs/tutorials/015/Handler.h b/docs/tutorials/015/Handler.h
index 7e3123f7cf2..73aa2573b0c 100644
--- a/docs/tutorials/015/Handler.h
+++ b/docs/tutorials/015/Handler.h
@@ -5,6 +5,11 @@
 #define HANDLER_H
 
 #include "ace/Svc_Handler.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Stream.h"
 #include "Protocol_Stream.h"
 
@@ -33,7 +38,7 @@ public:
         // differences between destroy() and close() so don't try to
         // use either for all cases.
     int close (u_long);
-    
+
 protected:
 
         // Respond to peer() activity.
diff --git a/docs/tutorials/015/Protocol_Stream.h b/docs/tutorials/015/Protocol_Stream.h
index 384e7240e4f..686d39126e0 100644
--- a/docs/tutorials/015/Protocol_Stream.h
+++ b/docs/tutorials/015/Protocol_Stream.h
@@ -5,6 +5,11 @@
 #define PROTOCOL_STREAM_H
 
 #include "ace/SOCK_Stream.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/Stream.h"
 
 // Shorthand for the stream.
@@ -46,18 +51,18 @@ public:
              _timeout = 0 );
 
         // Tell the Recv task to read some data and send it upstream.
-        // The data will pass through the protocol tasks and be queued 
+        // The data will pass through the protocol tasks and be queued
         // into the stream head reader task's message queue.  If
         // you've installed a _reader in open() then that task's
         // recv() method will see the message and may consume it
         // instead of passing it to the stream head for queueing.
     int get(void);
-    
+
     ACE_SOCK_Stream & peer(void)
         {
             return this->peer_;
         }
-    
+
 private:
         // Our peer connection
     ACE_SOCK_Stream peer_;
diff --git a/docs/tutorials/015/Protocol_Task.h b/docs/tutorials/015/Protocol_Task.h
index eeec1d71588..194809327ec 100644
--- a/docs/tutorials/015/Protocol_Task.h
+++ b/docs/tutorials/015/Protocol_Task.h
@@ -6,6 +6,10 @@
 
 #include "ace/Task.h"
 
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 /* A typical ACE_Task<> derivative that adds a few things appropriate
    to protocol stacks.
 */
@@ -20,13 +24,13 @@ public:
         // zero and let things proceed serially.  You might have a
         // need, however, for some of your tasks to have their own thread.
     Protocol_Task( int _thr_count );
-    
+
     ~Protocol_Task(void);
 
         // open() is invoked when the task is inserted into the stream.
     virtual int open(void *arg);
 
-        // close() is invoked when the stream is closed (flags will be 
+        // close() is invoked when the stream is closed (flags will be
         // set to '1') and when the svc() method exits (flags will be
         // '0').
     virtual int close(u_long flags);
@@ -36,13 +40,13 @@ public:
     virtual int put(ACE_Message_Block *message,
                     ACE_Time_Value *timeout);
 
-        // If you choose to activate the task then this method will be 
+        // If you choose to activate the task then this method will be
         // doing all of the work.
     virtual int svc(void);
 
 protected:
 
-        // Called by put() or svc() as necessary to process a block of 
+        // Called by put() or svc() as necessary to process a block of
         // data.
     int process(ACE_Message_Block * message, ACE_Time_Value *timeout);
 
@@ -57,7 +61,7 @@ protected:
         // the peer.
     virtual int send(ACE_Message_Block *message,
                      ACE_Time_Value *timeout);
-    
+
         // Tasks on the reader (upstream) side will be receiving data
         // that came from the peer.
     virtual int recv(ACE_Message_Block * message,
diff --git a/docs/tutorials/015/Recv.h b/docs/tutorials/015/Recv.h
index 4514f816aa9..a7058435bf5 100644
--- a/docs/tutorials/015/Recv.h
+++ b/docs/tutorials/015/Recv.h
@@ -19,7 +19,7 @@ public:
 
      // Give it someone to talk to...
     Recv( ACE_SOCK_Stream & _peer );
-    
+
     ~Recv(void);
 
      // Trigger a read from the socket
@@ -32,7 +32,7 @@ public:
         {
             return this->error_;
         }
-    
+
 protected:
 
     ACE_SOCK_Stream & peer(void)
diff --git a/docs/tutorials/015/Server.h b/docs/tutorials/015/Server.h
index 0e6b9f9c9cf..6b1eecf05e5 100644
--- a/docs/tutorials/015/Server.h
+++ b/docs/tutorials/015/Server.h
@@ -5,6 +5,11 @@
 #define SERVER_H
 
 #include "ace/Acceptor.h"
+
+#if !defined (ACE_LACKS_PRAGMA_ONCE)
+# pragma once
+#endif /* ACE_LACKS_PRAGMA_ONCE */
+
 #include "ace/SOCK_Acceptor.h"
 #include "Handler.h"
 
@@ -36,7 +41,7 @@ public:
     int run(void);
 
 private:
-        // This will accept client connection requests and instantiate 
+        // This will accept client connection requests and instantiate
         // a Handler object for each new connection.
     Acceptor acceptor_;
 
diff --git a/docs/tutorials/015/Xmit.h b/docs/tutorials/015/Xmit.h
index 7d8df91e0ef..097f3afdaba 100644
--- a/docs/tutorials/015/Xmit.h
+++ b/docs/tutorials/015/Xmit.h
@@ -21,14 +21,14 @@ public:
      // We must be given a valid peer when constructed.  Without that
      // we don't know who to send data to.
     Xmit( ACE_SOCK_Stream & _peer );
-    
+
     ~Xmit(void);
 
-     // As you know, close() will be called in a couple of ways by the 
+     // As you know, close() will be called in a couple of ways by the
      // ACE framework.  We use that opportunity to terminate the
      // connection to the peer.
     int close(u_long flags);
-    
+
 protected:
 
     ACE_SOCK_Stream & peer(void)