doc: remove space in nested templates

doc/manual/source/attributes.rst

@@ -546,7 +546,7 @@ default values.::
     Ptr<PointToPointNetDevice> net0 = CreateObject<PointToPointNetDevice>();
     n0->AddDevice(net0);
 
-    Ptr<Queue<Packet> > q = CreateObject<DropTailQueue<Packet> >();
+    Ptr<Queue<Packet>> q = CreateObject<DropTailQueue<Packet>> ();
     net0->AddQueue(q);
 
 At this point, we have created a single :cpp:class:`Node` (``n0``)
@@ -625,7 +625,7 @@ First, we observe that we can get a pointer to the (base class)
 
     PointerValue ptr;
     net0->GetAttribute("TxQueue", ptr);
-    Ptr<Queue<Packet> > txQueue = ptr.Get<Queue<Packet> >();
+    Ptr<Queue<Packet>> txQueue = ptr.Get<Queue<Packet>>();
 
 Using the :cpp:func:`GetObject()` function, we can perform a safe downcast
 to a :cpp:class:`DropTailQueue`.  The `NS_ASSERT` checks that the pointer is
@@ -633,8 +633,8 @@ valid.
 
 ::
 
-    Ptr<DropTailQueue<Packet> > dtq = txQueue->GetObject <DropTailQueue<Packet> >();
-    NS_ASSERT(dtq);
+    Ptr<DropTailQueue<Packet>> dtq = txQueue->GetObject<DropTailQueue<Packet>>();
+    NS_ASSERT (dtq);
 
 Next, we can get the value of an attribute on this queue.  We have introduced
 wrapper ``Value`` classes for the underlying data types, similar

doc/manual/source/logging.rst

@@ -355,7 +355,7 @@ In case you want to add logging statements to the methods of your template class
     {
     ...
     private:
-      std::list<Ptr<Item> > m_packets;          //!< the items in the queue
+      std::list<Ptr<Item>> m_packets;           //!< the items in the queue
       NS_LOG_TEMPLATE_DECLARE;                  //!< the log component
     };
 
@@ -386,7 +386,7 @@ In case you want to add logging statements to a static member template
 
     template <typename Item>
     void
-    NetDeviceQueue::PacketEnqueued(Ptr<Queue<Item> > queue,
+    NetDeviceQueue::PacketEnqueued(Ptr<Queue<Item>> queue,
                                    Ptr<NetDeviceQueueInterface> ndqi,
                                    uint8_t txq, Ptr<const Item> item)
     {

doc/tutorial/source/tracing.rst

@@ -635,7 +635,7 @@ variable in ``mobility-model.h`` you will find
 
 ::
 
-  TracedCallback<Ptr<const MobilityModel> > m_courseChangeTrace;
+  TracedCallback<Ptr<const MobilityModel>> m_courseChangeTrace;
 
 The type declaration ``TracedCallback`` identifies
 ``m_courseChangeTrace`` as a special list of Callbacks that can be
@@ -915,7 +915,7 @@ callback will always be ``void``.  The formal parameter list for a
 the declaration.  Recall that for our current example, this is in
 ``mobility-model.h``, where we have previously found::
 
-  TracedCallback<Ptr<const MobilityModel> > m_courseChangeTrace;
+  TracedCallback<Ptr<const MobilityModel>> m_courseChangeTrace;
 
 There is a one-to-one correspondence between the template parameter
 list in the declaration and the formal arguments of the callback
@@ -971,7 +971,7 @@ The first thing we need to look at is the declaration of the trace
 source.  Recall that this is in ``mobility-model.h``, where we have
 previously found::
 
-  TracedCallback<Ptr<const MobilityModel> > m_courseChangeTrace;
+  TracedCallback<Ptr<const MobilityModel>> m_courseChangeTrace;
 
 This declaration is for a template.  The template parameter is inside
 the angle-brackets, so we are really interested in finding out what
@@ -1052,7 +1052,7 @@ This tells you that TracedCallback is a templated class.  It has eight
 possible type parameters with default values.  Go back and compare
 this with the declaration you are trying to understand::
 
-  TracedCallback<Ptr<const MobilityModel> > m_courseChangeTrace;
+  TracedCallback<Ptr<const MobilityModel>> m_courseChangeTrace;
 
 The ``typename T1`` in the templated class declaration corresponds to
 the ``Ptr<const MobilityModel>`` in the declaration above.  All of the
@@ -1084,7 +1084,7 @@ instantiated for the declaration above, the compiler will replace
   void
   TracedCallback<Ptr<const MobilityModel>::ConnectWithoutContext ... cb
   {
-    Callback<void, Ptr<const MobilityModel> > cb;
+    Callback<void, Ptr<const MobilityModel>> cb;
     cb.Assign(callback);
     m_callbackList.push_back(cb);
   }
@@ -1115,7 +1115,7 @@ We are trying to figure out what the
 
 ::
 
-    Callback<void, Ptr<const MobilityModel> > cb;
+    Callback<void, Ptr<const MobilityModel>> cb;
 
 declaration means.  Now we are in a position to understand that the
 first (non-optional) template argument, ``void``, represents the
@@ -1850,7 +1850,7 @@ see that this trace source refers to
 ``PointToPointNetDevice::m_phyRxDropTrace``.  If you then look in
 ``src/point-to-point/model/point-to-point-net-device.h`` for this
 member variable, you will find that it is declared as a
-``TracedCallback<Ptr<const Packet> >``.  This should tell you that the
+``TracedCallback<Ptr<const Packet>>``.  This should tell you that the
 callback target should be a function that returns void and takes a
 single parameter which is a ``Ptr<const Packet>`` (assuming we use
 ``ConnectWithoutContext``) -- just what we have above.

src/buildings/doc/source/buildings-user.rst

@@ -30,7 +30,7 @@ As an example, let's create a residential 10 x 20 x 10 building::
     double y_max = 20.0;
     double z_min = 0.0;
     double z_max = 10.0;
-    Ptr<Building> b = CreateObject <Building>();
+    Ptr<Building> b = CreateObject<Building>();
     b->SetBoundaries(Box(x_min, x_max, y_min, y_max, z_min, z_max));
     b->SetBuildingType(Building::Residential);
     b->SetExtWallsType(Building::ConcreteWithWindows);

src/internet/doc/routing-overview.rst

@@ -272,7 +272,7 @@ be treated like a broadcast CSMA link).
 The GlobalRouteManager first walks the list of nodes and aggregates
 a GlobalRouter interface to each one as follows::
 
-  typedef std::vector < Ptr<Node> >::iterator Iterator;
+  typedef std::vector<Ptr<Node>>::iterator Iterator;
   for (Iterator i = NodeList::Begin(); i != NodeList::End(); i++)
     {
       Ptr<Node> node = *i;

src/internet/doc/tcp.rst

@@ -456,23 +456,21 @@ cwnd, 'bytes_acked' is reduced by the value of cwnd. Next, cwnd is incremented
 by a full-sized segment (SMSS).  In contrast, in ns-3 NewReno, cwnd is increased
 by (1/cwnd) with a rounding off due to type casting into int.
 
-::
-
-   :label: linuxrenocongavoid
+.. code-block::
+   :caption: Linux Reno `cwnd` update
 
    if (m_cWndCnt >= w)
-    {
+   {
       uint32_t delta = m_cWndCnt / w;
 
       m_cWndCnt -= delta * w;
       tcb->m_cWnd += delta * tcb->m_segmentSize;
       NS_LOG_DEBUG("Subtracting delta * w from m_cWndCnt " << delta * w);
-    }
+   }
 
 
-::
-
-   :label: newrenocongavoid
+.. code-block::
+   :caption: New Reno `cwnd` update
 
    if (segmentsAcked > 0)
     {
@@ -1842,8 +1840,7 @@ advertises a zero window. This can be accomplished by implementing the method
 CreateReceiverSocket, setting an Rx buffer value of 0 bytes (at line 6 of the
 following code):
 
-::
-
+.. code-block::
    :linenos:
    :emphasize-lines: 6,7,8
 
@@ -1990,8 +1987,7 @@ we expect the persistent timer to fire before any rWnd changes. When it fires,
 the SENDER should send a window probe, and the receiver should reply reporting
 again a zero window situation. At first, we investigates on what the sender sends:
 
-::
-
+.. code-block::
       :linenos:
       :emphasize-lines: 1,6,7,11
 
@@ -2024,8 +2020,7 @@ reader: edit the test, getting this value from the Attribute system), we need
 to check (line 6) between 6.0 and 7.0 simulated seconds that the probe is sent.
 Only one probe is allowed, and this is the reason for the check at line 11.
 
-::
-
+.. code-block::
    :linenos:
    :emphasize-lines: 6,7
 
@@ -2077,8 +2072,7 @@ the window should be greater than zero (and precisely, set to 2500):
 To be sure that the sender receives the window update, we can use the Rx
 method:
 
-::
-
+.. code-block::
    :linenos:
    :emphasize-lines: 5
 

src/lte/doc/source/lte-design.rst

@@ -3646,7 +3646,7 @@ the following new member variables::
 
   std::vector<EpcX2Sap::UlInterferenceOverloadIndicationItem>
     m_currentUlInterferenceOverloadIndicationList;
-  std::vector <EpcX2Sap::UlHighInterferenceInformationItem>
+  std::vector<EpcX2Sap::UlHighInterferenceInformationItem>
     m_currentUlHighInterferenceInformationList;
   EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;
 

src/lte/doc/source/lte-user.rst

@@ -560,7 +560,7 @@ It is to be noted that using other means to configure the frequency used by the
     double y_max = 20.0;
     double z_min = 0.0;
     double z_max = 10.0;
-    Ptr<Building> b = CreateObject <Building>();
+    Ptr<Building> b = CreateObject<Building>();
     b->SetBoundaries(Box(x_min, x_max, y_min, y_max, z_min, z_max));
     b->SetBuildingType(Building::Residential);
     b->SetExtWallsType(Building::ConcreteWithWindows);

src/stats/doc/statistics.rst

@@ -192,7 +192,7 @@ The first thing to do in implementing this experiment is developing the simulati
 
   ::
 
-    Ptr<CounterCalculator<> > appRx = CreateObject<CounterCalculator<> >();
+    Ptr<CounterCalculator<>> appRx = CreateObject<CounterCalculator<>>();
     appRx->SetKey("receiver-rx-packets");
     receiver->SetCounter(appRx);
     data.AddDataCalculator(appRx);

src/wave/doc/wave.rst

@@ -527,7 +527,7 @@ From <Your Vanet Routing Application>, usage is as follows:
     double m_gpsAccuracyNs;
     // array of distances (m) at which safety PDR shall be determined,
     // e.g. 50m, 100m, 200m, 300m, 400m, 500m, 600m, 800m, 1000m, and 1500m
-    std::vector <double> m_txSafetyRanges;
+    std::vector<double> m_txSafetyRanges;
     // used to get consistent random numbers across scenarios
     int64_t m_streamIndex;