From e45a3546c033251fa267320601ec6910a73989f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Deronne?= <sebastien.deronne@gmail.com>
Date: Fri, 25 Nov 2016 22:45:34 +0100
Subject: [PATCH] wifi: small code cleanup

---
 src/wifi/model/ap-wifi-mac.cc  |  3 +--
 src/wifi/model/dca-txop.cc     | 25 -------------------------
 src/wifi/model/mac-low.cc      | 10 +++++-----
 src/wifi/model/sta-wifi-mac.cc |  2 +-
 4 files changed, 7 insertions(+), 33 deletions(-)

diff --git a/src/wifi/model/ap-wifi-mac.cc b/src/wifi/model/ap-wifi-mac.cc
index fa88d8636..1fb41f109 100644
--- a/src/wifi/model/ap-wifi-mac.cc
+++ b/src/wifi/model/ap-wifi-mac.cc
@@ -82,6 +82,7 @@ ApWifiMac::GetTypeId (void)
 }
 
 ApWifiMac::ApWifiMac ()
+  : m_enableBeaconGeneration (false)
 {
   NS_LOG_FUNCTION (this);
   m_beaconDca = CreateObject<DcaTxop> ();
@@ -94,8 +95,6 @@ ApWifiMac::ApWifiMac ()
 
   //Let the lower layers know that we are acting as an AP.
   SetTypeOfStation (AP);
-
-  m_enableBeaconGeneration = false;
 }
 
 ApWifiMac::~ApWifiMac ()
diff --git a/src/wifi/model/dca-txop.cc b/src/wifi/model/dca-txop.cc
index eaa5b3021..f072419f1 100644
--- a/src/wifi/model/dca-txop.cc
+++ b/src/wifi/model/dca-txop.cc
@@ -663,31 +663,6 @@ DcaTxop::Cancel (void)
 {
   NS_LOG_FUNCTION (this);
   NS_LOG_DEBUG ("transmission cancelled");
-  /**
-   * This happens in only one case: in an AP, you have two DcaTxop:
-   *   - one is used exclusively for beacons and has a high priority.
-   *   - the other is used for everything else and has a normal
-   *     priority.
-   *
-   * If the normal queue tries to send a unicast data frame, but
-   * if the tx fails (ack timeout), it starts a backoff. If the beacon
-   * queue gets a tx oportunity during this backoff, it will trigger
-   * a call to this Cancel function.
-   *
-   * Since we are already doing a backoff, we will get access to
-   * the medium when we can, we have nothing to do here. We just
-   * ignore the cancel event and wait until we are given again a
-   * tx oportunity.
-   *
-   * Note that this is really non-trivial because each of these
-   * frames is assigned a sequence number from the same sequence
-   * counter (because this is a non-802.11e device) so, the scheme
-   * described here fails to ensure in-order delivery of frames
-   * at the receiving side. This, however, does not matter in
-   * this case because we assume that the receiving side does not
-   * update its <seq,ad> tupple for packets whose destination
-   * address is a broadcast address.
-   */
 }
 
 void
diff --git a/src/wifi/model/mac-low.cc b/src/wifi/model/mac-low.cc
index 9f1c3119f..d9db4d7e1 100644
--- a/src/wifi/model/mac-low.cc
+++ b/src/wifi/model/mac-low.cc
@@ -367,16 +367,16 @@ MacLow::MacLow ()
     m_endTxNoAckEvent (),
     m_currentPacket (0),
     m_listener (0),
+    m_lastNavStart (Seconds (0)),
+    m_lastNavDuration (Seconds (0)),
+    m_promisc (false),
+    m_ampdu (false),
     m_phyMacLowListener (0),
     m_ctsToSelfSupported (false),
+    m_sentMpdus (0),
     m_nTxMpdus (0)
 {
   NS_LOG_FUNCTION (this);
-  m_lastNavDuration = Seconds (0);
-  m_lastNavStart = Seconds (0);
-  m_promisc = false;
-  m_ampdu = false;
-  m_sentMpdus = 0;
   m_aggregateQueue = CreateObject<WifiMacQueue> ();
 }
 
diff --git a/src/wifi/model/sta-wifi-mac.cc b/src/wifi/model/sta-wifi-mac.cc
index 26ee7b41b..63f32c474 100644
--- a/src/wifi/model/sta-wifi-mac.cc
+++ b/src/wifi/model/sta-wifi-mac.cc
@@ -105,7 +105,7 @@ StaWifiMac::StaWifiMac ()
   : m_state (BEACON_MISSED),
     m_probeRequestEvent (),
     m_assocRequestEvent (),
-    m_beaconWatchdogEnd (Seconds (0.0))
+    m_beaconWatchdogEnd (Seconds (0))
 {
   NS_LOG_FUNCTION (this);