Skip to content
Snippets Groups Projects
  1. Jan 05, 2020
  2. Dec 12, 2019
  3. Sep 29, 2019
  4. Sep 26, 2019
  5. Jul 28, 2019
  6. Oct 30, 2018
  7. Apr 15, 2018
  8. Apr 13, 2018
  9. Jun 27, 2017
  10. Jun 30, 2017
  11. May 24, 2017
    • Cinder's avatar
      Downstream assault commit · 6300dc2a
      Cinder authored
      - Fix member init order
      - Use override specifier everywhere
      - Add required typename and template keywords
      - Replace smart pointer ctors with make functions where available
      - Replace 0 and NULL in pointer context with nullptr
      6300dc2a
  12. Mar 13, 2017
  13. Mar 08, 2017
  14. Mar 01, 2017
  15. Oct 03, 2016
  16. Sep 28, 2016
  17. Sep 15, 2016
    • Nat Goodspeed's avatar
      MAINT-5232: Normalize LLSingleton subclasses. · d2c3c2f9
      Nat Goodspeed authored
      A shocking number of LLSingleton subclasses had public constructors -- and in
      several instances, were being explicitly instantiated independently of the
      LLSingleton machinery. This breaks the new LLSingleton dependency-tracking
      machinery. It seems only fair that if you say you want an LLSingleton, there
      should only be ONE INSTANCE!
      
      Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the
      friend class LLSingleton<whatevah>;
      and explicitly declare a private nullary constructor.
      
      To try to enforce the LLSINGLETON() convention, introduce a new pure virtual
      LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might
      suspect, defined by the macro. If you declare an LLSingleton subclass without
      using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't
      instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro()
      implementation -- which will hopefully remind the coder.
      
      Trawl through ALL LLSingleton subclass definitions, sprinkling in
      LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit
      constructor declarations, public or private, along with relevant 'friend class
      LLSingleton<myself>' declarations. Where destructors are declared, move them
      into private section as well. Where the constructor was inline but nontrivial,
      move out of class body.
      
      Fix several LLSingleton abuses revealed by making ctors/dtors private:
      
      LLGlobalEconomy was both an LLSingleton and the base class for
      LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance
      contained another instance of the LLGlobalEconomy "singleton.") Extract
      LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that.
      LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy.
      
      LLToolGrab, an LLSingleton, was also explicitly instantiated by
      LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated,
      with trivial subclass LLToolGrab, the LLSingleton instance.
      
      (WARNING: LLToolGrabBase methods have an unnerving tendency to go after
      LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship
      between the instance in LLToolCompGun and the LLToolGrab singleton instance.)
      
      LLGridManager declared a variant constructor accepting (const std::string&),
      with the comment:
      // initialize with an explicity grid file for testing.
      As there is no evidence of this being called from anywhere, delete it.
      
      LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD
      parameter wasn't used, and as there is no evidence of it being passed from
      anywhere, delete the parameter.
      
      LLViewerWindow::shutdownViews() was checking LLNavigationBar::
      instanceExists(), then deleting its getInstance() pointer -- leaving a
      dangling LLSingleton instance pointer, a land mine if any subsequent code
      should attempt to reference it. Use deleteSingleton() instead.
      
      ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then
      explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the
      LLSingleton instance pointer pointing to an allocated-but-destroyed instance.
      Use deleteSingleton() instead.
      d2c3c2f9
  18. Jul 23, 2016
  19. Jul 18, 2016
  20. Mar 22, 2016
  21. Mar 07, 2016
  22. Feb 24, 2016
  23. Jan 26, 2016
  24. Jan 25, 2016
  25. Jan 11, 2016
  26. Jan 08, 2016
  27. Jan 07, 2016
  28. Jan 06, 2016
  29. Dec 17, 2015
  30. Dec 11, 2015
  31. Dec 10, 2015
  32. Dec 09, 2015
  33. Dec 08, 2015
  34. Dec 04, 2015
  35. Nov 10, 2015
  36. Jul 10, 2015
  37. Jul 07, 2015
  38. Jul 01, 2015
Loading